* Re: [PATCH] net/rds/Kconfig: RDS should depend on IPV6
From: Santosh Shilimkar @ 2018-07-25 22:36 UTC (permalink / raw)
To: Anders Roxell, ka-cheong.poon
Cc: davem, netdev, linux-rdma, rds-devel, linux-kernel
In-Reply-To: <20180725222008.32186-1-anders.roxell@linaro.org>
On 7/25/2018 3:20 PM, Anders Roxell wrote:
> Build error, implicit declaration of function __inet6_ehashfn shows up
> When RDS is enabled but not IPV6.
> net/rds/connection.c: In function ‘rds_conn_bucket’:
> net/rds/connection.c:67:9: error: implicit declaration of function ‘__inet6_ehashfn’; did you mean ‘__inet_ehashfn’? [-Werror=implicit-function-declaration]
> hash = __inet6_ehashfn(lhash, 0, fhash, 0, rds_hash_secret);
> ^~~~~~~~~~~~~~~
> __inet_ehashfn
>
> Current code adds IPV6 as a depends on in config RDS.
>
> Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
> net/rds/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/rds/Kconfig b/net/rds/Kconfig
> index 41f75563b54b..607128f10bcd 100644
> --- a/net/rds/Kconfig
> +++ b/net/rds/Kconfig
> @@ -1,7 +1,7 @@
>
> config RDS
> tristate "The RDS Protocol"
> - depends on INET
> + depends on INET && CONFIG_IPV6
This should build without CONFIG_IPV6 too.
Hi Ka-cheong,
Can you please loot at it ? I know you modified
lookup function to take always in6_addr now, but
probably hashing with '__inet_ehashfn' should
work too for non IPV6 address(s).
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Removed redundant checks for non-NULL
From: Dave Watson @ 2018-07-25 21:35 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180724112427.16574-1-vakul.garg@nxp.com>
On 07/24/18 04:54 PM, Vakul Garg wrote:
> Removed checks against non-NULL before calling kfree_skb() and
> crypto_free_aead(). These functions are safe to be called with NULL
> as an argument.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Acked-by: Dave Watson <davejwatson@fb.com>
^ permalink raw reply
* RE: [PATCH v3] hv_netvsc: Add per-cpu ethtool stats for netvsc
From: Yidong Ren @ 2018-07-25 22:54 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: Stephen Hemminger, netdev@vger.kernel.org, Haiyang Zhang,
linux-kernel@vger.kernel.org, Madhan Sivakumar,
devel@linuxdriverproject.org, David S. Miller
In-Reply-To: <87k1pkrj84.fsf@vitty.brq.redhat.com>
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> While you do for_each_present_cpu() in netvsc_get_ethtool_stats(),
> netvsc_get_pcpu_stats() does for_each_possible_cpu(). This looks
> inconsistent.
I made a mistake there. Thanks for catch me.
> The allocation you're doing here is short-lived so I would suggest you use
> possible_cpus everywhere. Even knowing there's no CPU hotplug on Hyper-
> V at this moment, it can appear later and we'll get a hard-to-find issue.
> Moreover, we may consider using netvsc driver on e.g. KVM with Hyper-V
> enlightenments and KVM has CPU hotplug already.
That would cause the output to be very long and useless.
I will submit a revision that allocates for num_possible_cpus, but only copy out stats for each present cpu.
-Yidong
^ permalink raw reply
* [PATCH net-next v2] tls: Skip zerocopy path for ITER_KVEC
From: Doron Roberts-Kedes @ 2018-07-25 21:48 UTC (permalink / raw)
To: David S . Miller; +Cc: Dave Watson, netdev, Doron Roberts-Kedes
In-Reply-To: <20180720181900.1073485-1-doronrk@fb.com>
The zerocopy path ultimately calls iov_iter_get_pages, which defines the
step function for ITER_KVECs as simply, return -EFAULT. Taking the
non-zerocopy path for ITER_KVECs avoids the unnecessary fallback.
See https://lore.kernel.org/lkml/20150401023311.GL29656@ZenIV.linux.org.uk/T/#u
for a discussion of why zerocopy for vmalloc data is not a good idea.
Discovered while testing NBD traffic encrypted with ktls.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
---
net/tls/tls_sw.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 1f3d9789af30..da584dc7d633 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -377,6 +377,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
int record_room;
bool full_record;
int orig_size;
+ bool is_kvec = msg->msg_iter.type & ITER_KVEC;
if (msg->msg_flags & ~(MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL))
return -ENOTSUPP;
@@ -425,8 +426,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
try_to_copy -= required_size - ctx->sg_encrypted_size;
full_record = true;
}
-
- if (full_record || eor) {
+ if (!is_kvec && (full_record || eor)) {
ret = zerocopy_from_iter(sk, &msg->msg_iter,
try_to_copy, &ctx->sg_plaintext_num_elem,
&ctx->sg_plaintext_size,
@@ -764,6 +764,7 @@ int tls_sw_recvmsg(struct sock *sk,
bool cmsg = false;
int target, err = 0;
long timeo;
+ bool is_kvec = msg->msg_iter.type & ITER_KVEC;
flags |= nonblock;
@@ -807,7 +808,7 @@ int tls_sw_recvmsg(struct sock *sk,
page_count = iov_iter_npages(&msg->msg_iter,
MAX_SKB_FRAGS);
to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
- if (to_copy <= len && page_count < MAX_SKB_FRAGS &&
+ if (!is_kvec && to_copy <= len && page_count < MAX_SKB_FRAGS &&
likely(!(flags & MSG_PEEK))) {
struct scatterlist sgin[MAX_SKB_FRAGS + 1];
int pages = 0;
--
2.17.1
^ permalink raw reply related
* [PATCH] bpf: verifier: BPF_MOV don't mark dst reg if src == dst
From: Arthur Fabre @ 2018-07-25 22:08 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev
When check_alu_op() handles a BPF_MOV between two registers,
it calls check_reg_arg() on the dst register, marking it as unbounded.
If the src and dst register are the same, this marks the src as
unbounded, which can lead to unexpected errors for further checks that
rely on bounds info.
check_alu_op() now only marks the dst register as unbounded if it
different from the src register.
Signed-off-by: Arthur Fabre <afabre@cloudflare.com>
---
kernel/bpf/verifier.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 63aaac52a265..ddfe3c544a80 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3238,8 +3238,9 @@ static int check_alu_op(struct bpf_verifier_env
*env, struct bpf_insn *insn)
}
}
- /* check dest operand */
- err = check_reg_arg(env, insn->dst_reg, DST_OP);
+ /* check dest operand, only mark if dest != src */
+ err = check_reg_arg(env, insn->dst_reg,
+ insn->dst_reg == insn->src_reg ?
DST_OP_NO_MARK : DST_OP);
if (err)
return err;
--
2.18.0
^ permalink raw reply related
* [PATCH] net/rds/Kconfig: RDS should depend on IPV6
From: Anders Roxell @ 2018-07-25 22:20 UTC (permalink / raw)
To: davem, santosh.shilimkar, ka-cheong.poon
Cc: netdev, linux-rdma, rds-devel, linux-kernel, Anders Roxell
Build error, implicit declaration of function __inet6_ehashfn shows up
When RDS is enabled but not IPV6.
net/rds/connection.c: In function ‘rds_conn_bucket’:
net/rds/connection.c:67:9: error: implicit declaration of function ‘__inet6_ehashfn’; did you mean ‘__inet_ehashfn’? [-Werror=implicit-function-declaration]
hash = __inet6_ehashfn(lhash, 0, fhash, 0, rds_hash_secret);
^~~~~~~~~~~~~~~
__inet_ehashfn
Current code adds IPV6 as a depends on in config RDS.
Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
net/rds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 41f75563b54b..607128f10bcd 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -1,7 +1,7 @@
config RDS
tristate "The RDS Protocol"
- depends on INET
+ depends on INET && CONFIG_IPV6
---help---
The RDS (Reliable Datagram Sockets) protocol provides reliable,
sequenced delivery of datagrams over Infiniband or TCP.
--
2.18.0
^ permalink raw reply related
* [PATCH RFC ipsec-next] xfrm: Check Reverse-Mark Lookup Before ADDSA/DELSA
From: Nathan Harold @ 2018-07-25 22:36 UTC (permalink / raw)
To: netdev; +Cc: Nathan Harold
It's possible to insert an SA into the SADB that will
preclude the lookup of other SAs when using the MARK
attribute. The problem occurs based on a particular
sequencing with the marks where a new mark matches
requests for the SA mark of an existing SA but the
inverse is not true. For an example:
1) Add SA with mark=0, mask=0
2) Add an otherwise-identical SA
with mark=0x1234, mask=0xFFFFFFFF
This will fail; however, if done in the reverse order
the second add will succeed:
1) Add an SA with mark=0x1234, mask=0xFFFFFFFF
2) Add an otherwise-identical SA
except with mark=0, mask=0
Then:
3) Delete the SA using mark=0x1234, mask=0xFFFFFFF
4) Dump the SADB, and there will be one SA, and it will
have mark=0x1234, mask=0xFFFFFFFF; the 0/0 SA will
be deleted
This patch addresses the problem by performing a
reverse-match on the mark and preventing ADDSA for
any SA that would 'shadow' an existing SA in the SADB.
This patch also address a bug where it was possible to
add an SA with a mark broader than its mask, which
could never be deleted:
1) ADDSA with mark=0x1234, mask=0xFF
2) DELSA with mark=0x1234, mask=ZZZZ; error=ESRCH
By applying both masks to each mark, bits outside the
mask of a given SA mark will be ignored, and the match
will succeed.
This patch does not make any changes to the 'data'
path, so SAs with such oddly-defined marks will still
be unmatch-able.
Signed-off-by: Nathan Harold <nharold@google.com>
---
net/xfrm/xfrm_state.c | 44 +++++++++++++++++++++++--------------------
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index b669262682c9..ee212a7c91a9 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -815,10 +815,10 @@ xfrm_init_tempstate(struct xfrm_state *x, const struct flowi *fl,
afinfo->init_temprop(x, tmpl, daddr, saddr);
}
-static struct xfrm_state *__xfrm_state_lookup(struct net *net, u32 mark,
- const xfrm_address_t *daddr,
- __be32 spi, u8 proto,
- unsigned short family)
+static struct xfrm_state *
+__xfrm_state_lookup(struct net *net, u32 mark, u32 mask,
+ const xfrm_address_t *daddr,
+ __be32 spi, u8 proto, unsigned short family)
{
unsigned int h = xfrm_spi_hash(net, daddr, spi, proto, family);
struct xfrm_state *x;
@@ -830,7 +830,7 @@ static struct xfrm_state *__xfrm_state_lookup(struct net *net, u32 mark,
!xfrm_addr_equal(&x->id.daddr, daddr, family))
continue;
- if ((mark & x->mark.m) != x->mark.v)
+ if ((mark ^ x->mark.v) & mask & x->mark.m)
continue;
if (!xfrm_state_hold_rcu(x))
continue;
@@ -840,10 +840,11 @@ static struct xfrm_state *__xfrm_state_lookup(struct net *net, u32 mark,
return NULL;
}
-static struct xfrm_state *__xfrm_state_lookup_byaddr(struct net *net, u32 mark,
- const xfrm_address_t *daddr,
- const xfrm_address_t *saddr,
- u8 proto, unsigned short family)
+static struct xfrm_state *
+__xfrm_state_lookup_byaddr(struct net *net, u32 mark, u32 mask,
+ const xfrm_address_t *daddr,
+ const xfrm_address_t *saddr,
+ u8 proto, unsigned short family)
{
unsigned int h = xfrm_src_hash(net, daddr, saddr, family);
struct xfrm_state *x;
@@ -855,7 +856,7 @@ static struct xfrm_state *__xfrm_state_lookup_byaddr(struct net *net, u32 mark,
!xfrm_addr_equal(&x->props.saddr, saddr, family))
continue;
- if ((mark & x->mark.m) != x->mark.v)
+ if ((mark ^ x->mark.v) & mask & x->mark.m)
continue;
if (!xfrm_state_hold_rcu(x))
continue;
@@ -869,15 +870,14 @@ static inline struct xfrm_state *
__xfrm_state_locate(struct xfrm_state *x, int use_spi, int family)
{
struct net *net = xs_net(x);
- u32 mark = x->mark.v & x->mark.m;
if (use_spi)
- return __xfrm_state_lookup(net, mark, &x->id.daddr,
- x->id.spi, x->id.proto, family);
+ return __xfrm_state_lookup(net, x->mark.v, x->mark.m,
+ &x->id.daddr, x->id.spi,
+ x->id.proto, family);
else
- return __xfrm_state_lookup_byaddr(net, mark,
- &x->id.daddr,
- &x->props.saddr,
+ return __xfrm_state_lookup_byaddr(net, x->mark.v, x->mark.m,
+ &x->id.daddr, &x->props.saddr,
x->id.proto, family);
}
@@ -985,8 +985,10 @@ xfrm_state_find(const xfrm_address_t *daddr, const xfrm_address_t *saddr,
x = best;
if (!x && !error && !acquire_in_progress) {
if (tmpl->id.spi &&
- (x0 = __xfrm_state_lookup(net, mark, daddr, tmpl->id.spi,
- tmpl->id.proto, encap_family)) != NULL) {
+ (x0 = __xfrm_state_lookup(net, mark, 0xFFFFFFFF,
+ daddr, tmpl->id.spi,
+ tmpl->id.proto,
+ encap_family)) != NULL) {
to_put = x0;
error = -EEXIST;
goto out;
@@ -1617,7 +1619,8 @@ xfrm_state_lookup(struct net *net, u32 mark, const xfrm_address_t *daddr, __be32
struct xfrm_state *x;
rcu_read_lock();
- x = __xfrm_state_lookup(net, mark, daddr, spi, proto, family);
+ x = __xfrm_state_lookup(net, mark, 0xFFFFFFFF,
+ daddr, spi, proto, family);
rcu_read_unlock();
return x;
}
@@ -1631,7 +1634,8 @@ xfrm_state_lookup_byaddr(struct net *net, u32 mark,
struct xfrm_state *x;
spin_lock_bh(&net->xfrm.xfrm_state_lock);
- x = __xfrm_state_lookup_byaddr(net, mark, daddr, saddr, proto, family);
+ x = __xfrm_state_lookup_byaddr(net, mark, 0xFFFFFFFF,
+ daddr, saddr, proto, family);
spin_unlock_bh(&net->xfrm.xfrm_state_lock);
return x;
}
--
2.18.0.345.g5c9ce644c3-goog
^ permalink raw reply related
* [PATCH net] netdevsim: don't leak devlink resources
From: Jakub Kicinski @ 2018-07-25 22:39 UTC (permalink / raw)
To: davem; +Cc: dsahern, oss-drivers, netdev, Jakub Kicinski
Devlink resources registered with devlink_resource_register() have
to be unregistered.
Fixes: 37923ed6b8ce ("netdevsim: Add simple FIB resource controller via devlink")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
drivers/net/netdevsim/devlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/netdevsim/devlink.c b/drivers/net/netdevsim/devlink.c
index ba663e5af168..5135fc371f01 100644
--- a/drivers/net/netdevsim/devlink.c
+++ b/drivers/net/netdevsim/devlink.c
@@ -207,6 +207,7 @@ void nsim_devlink_teardown(struct netdevsim *ns)
struct net *net = nsim_to_net(ns);
bool *reg_devlink = net_generic(net, nsim_devlink_id);
+ devlink_resources_unregister(ns->devlink, NULL);
devlink_unregister(ns->devlink);
devlink_free(ns->devlink);
ns->devlink = NULL;
--
2.17.1
^ permalink raw reply related
* Re: pahole + BTF was: Re: [Question] bpf: about a new 'tools/bpf/bpf_dwarf2btf'
From: Daniel Borkmann @ 2018-07-26 0:26 UTC (permalink / raw)
To: Martin KaFai Lau, Taeung Song, Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov, netdev, Thomas Girard, Martin Cermak,
linux-kernel, acme
In-Reply-To: <20180725201122.h7ostqw3qtfvz7sn@kafai-mbp.dhcp.thefacebook.com>
On 07/25/2018 10:11 PM, Martin KaFai Lau wrote:
> On Thu, Jul 26, 2018 at 04:21:31AM +0900, Taeung Song wrote:
>> On 07/26/2018 03:27 AM, Taeung Song wrote:
>>> On 07/26/2018 02:52 AM, Arnaldo Carvalho de Melo wrote:
>>>> Em Thu, Jul 26, 2018 at 02:23:32AM +0900, Taeung Song escreveu:
>>>>> Hi,
>>>>>
>>>>> Building bpf programs with .BTF section,
>>>>> I thought it'd be better to convert dwarf info to .BTF by
>>>>> a new tool such as 'tools/bpf/bpf_dwarf2btf' instead of pahole
>>>>> in the future.
>>>>> Currently for bpf binary that have .BTF section,
>>>>> we need to use pahole from https://github.com/iamkafai/pahole/tree/btf
>>>>> with the command line such as "pahole -J bpf_prog.o".
>>>>> I think it is great but if implementing new 'bpf_dwarf2btf'
>>>>> (dwarf parsing + btf encoder code written by Martin KaFai Lau on
>>>>> the pahole project i.e. btf.h, btf_encoder.c, btf_encoder.h,
>>>>> libbtf.c, libbtf.h),
>>>>> BPF developers would more easily use functionalities based on BTF.
>>>>
>>>> What would be easier exactly? Not having to install a package but build
>>>> it from the kernel sources?
>>>>
>>>> Many kernel developers already have pahole installed for other uses, so
>>>> no need to install anything.
>>>
>>> Understood, but I think there are many non-kernel developers
>>> developing BPF programs and they mightn't have or use pahole.
>>>
>>> So, if providing the 'dwarf2btf' feature on tools/bpf or tools/bpf/bpftool,
>>> non-kernel developers can also more easily build bpf prog with .BPF, no ?
> Some quick thoughts,
> IMO, I suspect if it is in the distro's pahole package, it should be easy
> enough for kernel and non kernel developer to install.
> BTF usage is still evolving, we might re-evaluate going forward but at this
> point I think leveraging pahole's existing capability is a good option.
Agree, if there will be a future use-case where pahole might not be well-fitting,
we could add it to bpftool then so I wouldn't rule it out, but for the functionality
right now it seems good to reuse it. Presumably BPF developers have it installed
anyway to inspect struct padding from BPF obj files.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives
From: David Miller @ 2018-07-25 23:21 UTC (permalink / raw)
To: ncardwell; +Cc: brakmo, ycheng, daniel, netdev, Kernel-team, ast, eric.dumazet
In-Reply-To: <CADVnQy=RAP6QYdCpkXNKXGQgS0TTWof=VazUeN=jHqtcTZxFig@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Tue, 24 Jul 2018 21:57:27 -0400
> On Tue, Jul 24, 2018 at 1:42 PM Lawrence Brakmo <brakmo@fb.com> wrote:
>>
>> Note that without this fix the 99% latencies when doing 10KB RPCs
>> in a congested network using DCTCP are 40ms vs. 190us with the patch.
>> Also note that these 40ms high tail latencies started after commit
>> 3759824da87b30ce7a35b4873b62b0ba38905ef5 in Jul 2015,
>> which triggered the bugs/features we are fixing/adding. I agree it is a
>> debatable whether it is a bug fix or a feature improvement and I am
>> fine either way.
>
> Good point. The fact that this greatly mitigates a regression in DCTCP
> performance resulting from 3759824da87b30ce7a35b4873b62b0ba38905ef5
> ("tcp: PRR uses CRB mode by default and SS mode conditionally") IMHO
> seems to be a good argument for putting this patch ("tcp: ack
> immediately when a cwr packet arrives") in the "net" branch and stable
> releases.
Thus, applied to 'net' and queued up for -stable.
^ permalink raw reply
* Re: pull-request: can 2018-07-23
From: David Miller @ 2018-07-25 23:26 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, linux-can
In-Reply-To: <738a1779-1375-1159-54b7-39a327509b61@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 24 Jul 2018 09:27:30 +0200
> Thanks David. Can you please merge net into next-next, as I've some
> patches for net-next that would result in a merge conflict between net
> and net-next later.
This has now been done.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net/mlx5: Offload setting/matching on tunnel tos/ttl
From: David Miller @ 2018-07-25 23:29 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, saeedm
In-Reply-To: <1532429975-6490-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Tue, 24 Jul 2018 13:59:32 +0300
> This series enables mlx5 offloading of tc eswitch rules that set
> tos/ttl (encap) or match on them (decap) for tunnels.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_core: Allow MTTs starting at any index
From: David Miller @ 2018-07-25 23:30 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, eli, anaty
In-Reply-To: <1532431905-14372-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 24 Jul 2018 14:31:45 +0300
> Allow obtaining MTTs starting at any index,
> thus give a better cache utilization.
>
> For this, allow setting log_mtts_per_seg to 0, and use
> this in default.
>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> Signed-off-by: Eli Cohen <eli@mellanox.co.il>
> Signed-off-by: Anaty Rahamim Bar Kat <anaty@mellanox.com>
> Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: cls_flower: Use correct inline function for assignment of vlan tpid
From: David Miller @ 2018-07-25 23:34 UTC (permalink / raw)
To: jianbol; +Cc: netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <20180725023125.26925-1-jianbol@mellanox.com>
From: Jianbo Liu <jianbol@mellanox.com>
Date: Wed, 25 Jul 2018 02:31:25 +0000
> This fixes the following sparse warning:
>
> net/sched/cls_flower.c:1356:36: warning: incorrect type in argument 3 (different base types)
> net/sched/cls_flower.c:1356:36: expected unsigned short [unsigned] [usertype] value
> net/sched/cls_flower.c:1356:36: got restricted __be16 [usertype] vlan_tpid
>
> Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] tcp: make function tcp_retransmit_stamp() static
From: David Miller @ 2018-07-25 23:36 UTC (permalink / raw)
To: weiyongjun1
Cc: edumazet, jmaxwell37, kuznet, yoshfuji, netdev, kernel-janitors
In-Reply-To: <1532498767-188296-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 25 Jul 2018 06:06:07 +0000
> Fixes the following sparse warnings:
>
> net/ipv4/tcp_timer.c:25:5: warning:
> symbol 'tcp_retransmit_stamp' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 02/10] audit: log container info of syscalls
From: Richard Guy Briggs @ 2018-07-26 0:51 UTC (permalink / raw)
To: Paul Moore
Cc: sgrubb, cgroups, containers, linux-api, linux-audit,
linux-fsdevel, linux-kernel, netdev, ebiederm, luto, carlos,
dhowells, viro, simo, Eric Paris, serge
In-Reply-To: <CAHC9VhTkuf+2BwJp399-NzSgQyp21GgY1SZVDboDdXgpvEV=pQ@mail.gmail.com>
On 2018-07-23 14:31, Paul Moore wrote:
> On Mon, Jul 23, 2018 at 12:48 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Monday, July 23, 2018 11:11:48 AM EDT Richard Guy Briggs wrote:
> > > On 2018-07-23 09:19, Steve Grubb wrote:
> > > > On Sunday, July 22, 2018 4:55:10 PM EDT Richard Guy Briggs wrote:
> > > > > On 2018-07-22 09:32, Steve Grubb wrote:
> > > > > > On Saturday, July 21, 2018 4:29:30 PM EDT Richard Guy Briggs wrote:
> > > > > > > > > + * audit_log_contid - report container info
> > > > > > > > > + * @tsk: task to be recorded
> > > > > > > > > + * @context: task or local context for record
> > > > > > > > > + * @op: contid string description
> > > > > > > > > + */
> > > > > > > > > +int audit_log_contid(struct task_struct *tsk,
> > > > > > > > > + struct audit_context *context,
> > > > > > > > > char
> > > > > > > > > *op)
> > > > > > > > > +{
> > > > > > > > > + struct audit_buffer *ab;
> > > > > > > > > +
> > > > > > > > > + if (!audit_contid_set(tsk))
> > > > > > > > > + return 0;
> > > > > > > > > + /* Generate AUDIT_CONTAINER record with container ID */
> > > > > > > > > + ab = audit_log_start(context, GFP_KERNEL,
> > > > > > > > > AUDIT_CONTAINER);
> > > > > > > > > + if (!ab)
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > + audit_log_format(ab, "op=%s contid=%llu",
> > > > > > > > > + op, audit_get_contid(tsk));
> > > > > > > >
> > > > > > > > Can you explain your reason for including an "op" field in this
> > > > > > > > record
> > > > > > > > type? I've been looking at the rest of the patches in this
> > > > > > > > patchset
> > > > > > > > and it seems to be used more as an indicator of the record's
> > > > > > > > generating context rather than any sort of audit container ID
> > > > > > > > operation.
> > > > > > >
> > > > > > > "action" might work, but that's netfilter and numeric... "kind"?
> > > > > > > Nothing else really seems to fit from a field name, type or lack of
> > > > > > > searchability perspective.
> > > > > > >
> > > > > > > Steve, do you have an opinion?
> > > > > >
> > > > > > We only have 1 sample event where we have op=task. What are the other
> > > > > > possible values?
> > > > >
> > > > > For the AUDIT_CONTAINER record we have op= "task", "target" (from the
> > > > > ptrace and signals patch), "tty".
> > > > >
> > > > > For the AUDIT_CONTAINER_ID record we have "op=set".
> > > >
> > > > Since the purpose of this record is to log the container id, I think that
> > > > is all that is needed. We can get the context from the other records in
> > > > the event. I'd suggest dropping the "op" field.
> > >
> > > Ok, the information above it for two different audit container
> > > identifier records. Which one should drop the "op=" field? Both? Or
> > > just the AUDIT_CONTAINER record? The AUDIT_CONTAINER_ID record (which
> > > might be renamed) could use it to distinguish a "set" record from a
> > > dropped audit container identifier that is no longer registered by any
> > > task or namespace.
> >
> > Neither of them need it. All they need to do is state the container that is
> > being acted upon.
>
> I think we should keep the "op" field for audit container ID
> management operations, even though we really only have a "set"
> operation at the moment, but the others should drop the "op" field
> (see my previous emails in this thread).
In fact, I'd like to question the wisdom of dropping this field and
perhaps fine a better or new name for it, since these contid records
could be multiple and different from the primary task that is generating
this record. In particular, there are extra contid records generated by
the ptrace/signals patch that could be from other processes in other
containers that I mentioned in a branch thread that got dropped
including the auc_pids data and the target_pid also attached to the
primary task's audit context.
> paul moore
> www.paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH net-next] net: igmp: make function __ip_mc_inc_group() static
From: David Miller @ 2018-07-25 23:38 UTC (permalink / raw)
To: weiyongjun1; +Cc: kuznet, yoshfuji, liuhangbin, netdev, kernel-janitors
In-Reply-To: <1532498773-188363-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 25 Jul 2018 06:06:13 +0000
> Fixes the following sparse warnings:
>
> net/ipv4/igmp.c:1391:6: warning:
> symbol '__ip_mc_inc_group' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied to 'net'.
^ permalink raw reply
* Re: [PATCH net-next] lan743x: Make symbol lan743x_pm_ops static
From: David Miller @ 2018-07-25 23:38 UTC (permalink / raw)
To: weiyongjun1; +Cc: bryan.whitehead, UNGLinuxDriver, netdev, kernel-janitors
In-Reply-To: <1532499076-191548-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 25 Jul 2018 06:11:16 +0000
> Fixes the following sparse warning:
>
> drivers/net/ethernet/microchip/lan743x_main.c:2944:25: warning:
> symbol 'lan743x_pm_ops' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH bpf-next v2] bpf: add End.DT6 action to bpf_lwt_seg6_action helper
From: Mathieu Xhonneux @ 2018-07-25 23:46 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180725211317.aqim6j74u5zzjs6w@kafai-mbp.dhcp.thefacebook.com>
2018-07-25 23:13 GMT+02:00 Martin KaFai Lau <kafai@fb.com>:
>> v2: - changed true/false -> 1/0
> hmmm...I thought I was asking to replace 1/0 with true/false. More
> below.
Silly me, I read your indication backwards. Agreed.
@Daniel: sorry for this one, sending a v3.
^ permalink raw reply
* Re: [PATCH net-next 00/17] mlxsw: Introduce algorithmic TCAM support
From: David Miller @ 2018-07-25 23:46 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw
In-Reply-To: <20180725062406.3342-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Wed, 25 Jul 2018 09:23:49 +0300
> The Spectrum-2 ASIC uses an algorithmic TCAM (A-TCAM) where multiple
> exact matches lookups are performed instead of a single lookup as with
> standard circuit TCAM (C-TCAM) memory. This allows for higher scale and
> reduced power consumption.
>
> The lookups are performed by masking a packet using different masks
> (e.g., {dst_ip/24, ethtype}) defined for the region and looking for an
> exact match. Eventually, the rule with the highest priority will be
> picked.
>
> Since the number of masks per-region is limited, the ASIC includes a
> C-TCAM that can be used as a spill area for rules that do not fit into
> the A-TCAM.
...
Looks great, series applied, thanks!
^ permalink raw reply
* Re: [181992] ...8xx/816: net-tcp_bbr: improve DCTCP ECN delayed ACK
From: Laurent Chavey @ 2018-07-25 23:50 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: netdev@vger.kernel.org, Neal Cardwell
In-Reply-To: <0000000000005eb9ac0571dad101@google.com>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
Are we ok with all the BBR patches for 816 (i.e. we did extensive testing?).
On Wed, Jul 25, 2018 at 3:58 PM kernel-commit-validator (Code Review) <
prodkernel-gerrit-commits@google.com> wrote:
> GA release commit message is missing a Release-Commit: tag indicating the
> original SHA1.
>
>
> Current Buildbot status: http://prodkernel-bot/?review=181992.
>
> Patch set 1:Code-Review -2
>
> View Change <https://prodkernel-review.git.corp.google.com/181992>
>
> 1 comment:
>
> -
>
> Commit Message:
> <https://prodkernel-review.git.corp.google.com/#/c/181992/1//COMMIT_MSG>
> -
>
> Patch Set #1, Line 15:
> <https://prodkernel-review.git.corp.google.com/#/c/181992/1//COMMIT_MSG@15> CherryPick-4.3.5-SHA1:
> 7205c1178312155984ab4047b1e4459bde572f8f
>
> Unexpected tag; expected CherryPick-8xx-SHA1:
>
> To view, visit change 181992
> <https://prodkernel-review.git.corp.google.com/181992>. To unsubscribe,
> or for help writing mail filters, visit settings
> <https://prodkernel-review.git.corp.google.com/settings>.
> Gerrit-Project: kernel/release/8xx
> Gerrit-Branch: 816
> Gerrit-Change-Id: Ied39c2f4ef576c697b0064d6b810b47282796388
> Gerrit-Change-Number: 181992
> Gerrit-PatchSet: 1
> Gerrit-Owner: Yuchung Cheng <ycheng@google.com>
> Gerrit-Reviewer: Greg Thelen <gthelen@google.com>
> Gerrit-Reviewer: Laurent Chavey <chavey@google.com>
> Gerrit-Reviewer: kernel-commit-validator
> Gerrit-CC: Neal Cardwell <ncardwell@google.com>
> Gerrit-Comment-Date: Wed, 25 Jul 2018 22:58:32 +0000
> Gerrit-HasComments: Yes
> Gerrit-Has-Labels: Yes
> Gerrit-MessageType: comment
>
[-- Attachment #2: Type: text/html, Size: 3301 bytes --]
^ permalink raw reply
* Re: [PATCH] samples/bpf: Add BTF build flags to Makefile
From: Jakub Kicinski @ 2018-07-26 1:16 UTC (permalink / raw)
To: Taeung Song
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, linux-kernel,
Martin KaFai Lau
In-Reply-To: <20180725163039.2838-1-treeze.taeung@gmail.com>
On Thu, 26 Jul 2018 01:30:39 +0900, Taeung Song wrote:
> To smoothly test BTF supported binary on samples/bpf,
> let samples/bpf/Makefile probe llc, pahole and
> llvm-objcopy for BPF support and use them
> like tools/testing/selftests/bpf/Makefile
> changed from the commit c0fa1b6c3efc ("bpf: btf:
> Add BTF tests")
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
> ---
> samples/bpf/Makefile | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 1303af10e54d..e079266360a3 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -191,6 +191,8 @@ HOSTLOADLIBES_xdpsock += -pthread
> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> LLC ?= llc
> CLANG ?= clang
> +LLVM_OBJCOPY ?= llvm-objcopy
> +BTF_PAHOLE ?= pahole
>
> # Detect that we're cross compiling and use the cross compiler
> ifdef CROSS_COMPILE
> @@ -198,6 +200,20 @@ HOSTCC = $(CROSS_COMPILE)gcc
> CLANG_ARCH_ARGS = -target $(ARCH)
> endif
>
> +BTF_LLC_PROBE := $(shell $(LLC) -march=bpf -mattr=help 2>&1 | grep dwarfris)
> +BTF_PAHOLE_PROBE := $(shell $(BTF_PAHOLE) --help 2>&1 | grep BTF)
> +BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --help 2>&1 | grep -i 'usage.*llvm')
> +
> +ifneq ($(BTF_LLC_PROBE),)
> +ifneq ($(BTF_PAHOLE_PROBE),)
> +ifneq ($(BTF_OBJCOPY_PROBE),)
Nice patch! FWIW you could consider using $(and ...) here:
ifneq ($(and $(BTF_LLC_PROBE),$(BTF_PAHOLE_PROBE),$(BTF_OBJCOPY_PROBE)),)
https://www.gnu.org/software/make/manual/html_node/Conditional-Functions.html#Conditional-Functions
Not sure it's worth a respin..
> + EXTRA_CFLAGS += -g
> + LLC_FLAGS += -mattr=dwarfris
> + DWARF2BTF = y
> +endif
> +endif
> +endif
> +
> # Trick to allow make to be run from this directory
> all:
> $(MAKE) -C ../../ $(CURDIR)/ BPF_SAMPLES_PATH=$(CURDIR)
> @@ -256,4 +272,7 @@ $(obj)/%.o: $(src)/%.c
> -Wno-gnu-variable-sized-type-not-at-end \
> -Wno-address-of-packed-member -Wno-tautological-compare \
> -Wno-unknown-warning-option $(CLANG_ARCH_ARGS) \
> - -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
> + -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf $(LLC_FLAGS) -filetype=obj -o $@
> +ifeq ($(DWARF2BTF),y)
> + $(BTF_PAHOLE) -J $@
> +endif
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the bpf tree
From: Stephen Rothwell @ 2018-07-26 1:19 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Okash Khawaja,
Daniel Borkmann, Alexei Starovoitov, Martin KaFai Lau
[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got conflicts in:
tools/lib/bpf/btf.c
tools/lib/bpf/btf.h
between commits:
5b891af7fca1 ("bpf: Replace [u]int32_t and [u]int64_t in libbpf")
38d5d3b3d5db ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")
from the bpf tree and commit:
92b57121ca79 ("bpf: btf: export btf types and name by offset from lib")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/lib/bpf/btf.c
index 2d270c560df3,03161be094b4..000000000000
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@@ -269,9 -259,29 +266,29 @@@ __s64 btf__resolve_size(const struct bt
return nelems * size;
}
+ int btf__resolve_type(const struct btf *btf, __u32 type_id)
+ {
+ const struct btf_type *t;
+ int depth = 0;
+
+ t = btf__type_by_id(btf, type_id);
+ while (depth < MAX_RESOLVE_DEPTH &&
+ !btf_type_is_void_or_null(t) &&
+ IS_MODIFIER(BTF_INFO_KIND(t->info))) {
+ type_id = t->type;
+ t = btf__type_by_id(btf, type_id);
+ depth++;
+ }
+
+ if (depth == MAX_RESOLVE_DEPTH || btf_type_is_void_or_null(t))
+ return -EINVAL;
+
+ return type_id;
+ }
+
-int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
+__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
{
- uint32_t i;
+ __u32 i;
if (!strcmp(type_name, "void"))
return 0;
@@@ -368,3 -379,20 +385,11 @@@ int btf__fd(const struct btf *btf
{
return btf->fd;
}
+
+ const char *btf__name_by_offset(const struct btf *btf, __u32 offset)
+ {
+ if (offset < btf->hdr->str_len)
+ return &btf->strings[offset];
+ else
+ return NULL;
+ }
-
-const struct btf_type *btf__type_by_id(const struct btf *btf,
- __u32 type_id)
-{
- if (type_id > btf->nr_types)
- return NULL;
-
- return btf->types[type_id];
-}
diff --cc tools/lib/bpf/btf.h
index e2a09a155f84,24f361d99a5e..000000000000
--- a/tools/lib/bpf/btf.h
+++ b/tools/lib/bpf/btf.h
@@@ -15,10 -14,12 +15,12 @@@ typedef int (*btf_print_fn_t)(const cha
__attribute__((format(printf, 1, 2)));
void btf__free(struct btf *btf);
-struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
-int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
-int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
+struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
+__s32 btf__find_by_name(const struct btf *btf, const char *type_name);
- const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id);
+__s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
+ int btf__resolve_type(const struct btf *btf, __u32 type_id);
int btf__fd(const struct btf *btf);
+ const char *btf__name_by_offset(const struct btf *btf, __u32 offset);
+ const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id);
#endif
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH bpf-next v3] bpf: add End.DT6 action to bpf_lwt_seg6_action helper
From: Mathieu Xhonneux @ 2018-07-26 2:10 UTC (permalink / raw)
To: netdev; +Cc: daniel, alexei.starovoitov
The seg6local LWT provides the End.DT6 action, which allows to
decapsulate an outer IPv6 header containing a Segment Routing Header
(SRH), full specification is available here:
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05
This patch adds this action now to the seg6local BPF
interface. Since it is not mandatory that the inner IPv6 header also
contains a SRH, seg6_bpf_srh_state has been extended with a pointer to
a possible SRH of the outermost IPv6 header. This helps assessing if the
validation must be triggered or not, and avoids some calls to
ipv6_find_hdr.
v3: s/1/true, s/0/false for boolean values
v2: - changed true/false -> 1/0
- preempt_enable no longer called in first conditional block
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
---
include/net/seg6_local.h | 4 ++-
net/core/filter.c | 89 ++++++++++++++++++++++++++++++++----------------
net/ipv6/seg6_local.c | 50 +++++++++++++++++----------
3 files changed, 95 insertions(+), 48 deletions(-)
diff --git a/include/net/seg6_local.h b/include/net/seg6_local.h
index 661fd5b4d3e0..08359e2d8b35 100644
--- a/include/net/seg6_local.h
+++ b/include/net/seg6_local.h
@@ -21,10 +21,12 @@
extern int seg6_lookup_nexthop(struct sk_buff *skb, struct in6_addr *nhaddr,
u32 tbl_id);
+extern bool seg6_bpf_has_valid_srh(struct sk_buff *skb);
struct seg6_bpf_srh_state {
- bool valid;
+ struct ipv6_sr_hdr *srh;
u16 hdrlen;
+ bool valid;
};
DECLARE_PER_CPU(struct seg6_bpf_srh_state, seg6_bpf_srh_states);
diff --git a/net/core/filter.c b/net/core/filter.c
index 104d560946da..355430cfeb76 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4542,26 +4542,28 @@ BPF_CALL_4(bpf_lwt_seg6_store_bytes, struct sk_buff *, skb, u32, offset,
{
struct seg6_bpf_srh_state *srh_state =
this_cpu_ptr(&seg6_bpf_srh_states);
+ struct ipv6_sr_hdr *srh = srh_state->srh;
void *srh_tlvs, *srh_end, *ptr;
- struct ipv6_sr_hdr *srh;
int srhoff = 0;
- if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
+ if (srh == NULL)
return -EINVAL;
- srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
srh_tlvs = (void *)((char *)srh + ((srh->first_segment + 1) << 4));
srh_end = (void *)((char *)srh + sizeof(*srh) + srh_state->hdrlen);
ptr = skb->data + offset;
if (ptr >= srh_tlvs && ptr + len <= srh_end)
- srh_state->valid = 0;
+ srh_state->valid = false;
else if (ptr < (void *)&srh->flags ||
ptr + len > (void *)&srh->segments)
return -EFAULT;
if (unlikely(bpf_try_make_writable(skb, offset + len)))
return -EFAULT;
+ if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
+ return -EINVAL;
+ srh_state->srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
memcpy(skb->data + offset, from, len);
return 0;
@@ -4577,52 +4579,79 @@ static const struct bpf_func_proto bpf_lwt_seg6_store_bytes_proto = {
.arg4_type = ARG_CONST_SIZE
};
-BPF_CALL_4(bpf_lwt_seg6_action, struct sk_buff *, skb,
- u32, action, void *, param, u32, param_len)
+static void bpf_update_srh_state(struct sk_buff *skb)
{
struct seg6_bpf_srh_state *srh_state =
this_cpu_ptr(&seg6_bpf_srh_states);
- struct ipv6_sr_hdr *srh;
int srhoff = 0;
- int err;
-
- if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
- return -EINVAL;
- srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
-
- if (!srh_state->valid) {
- if (unlikely((srh_state->hdrlen & 7) != 0))
- return -EBADMSG;
-
- srh->hdrlen = (u8)(srh_state->hdrlen >> 3);
- if (unlikely(!seg6_validate_srh(srh, (srh->hdrlen + 1) << 3)))
- return -EBADMSG;
- srh_state->valid = 1;
+ if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0) {
+ srh_state->srh = NULL;
+ } else {
+ srh_state->srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
+ srh_state->hdrlen = srh_state->srh->hdrlen << 3;
+ srh_state->valid = true;
}
+}
+
+BPF_CALL_4(bpf_lwt_seg6_action, struct sk_buff *, skb,
+ u32, action, void *, param, u32, param_len)
+{
+ struct seg6_bpf_srh_state *srh_state =
+ this_cpu_ptr(&seg6_bpf_srh_states);
+ int hdroff = 0;
+ int err;
switch (action) {
case SEG6_LOCAL_ACTION_END_X:
+ if (!seg6_bpf_has_valid_srh(skb))
+ return -EBADMSG;
if (param_len != sizeof(struct in6_addr))
return -EINVAL;
return seg6_lookup_nexthop(skb, (struct in6_addr *)param, 0);
case SEG6_LOCAL_ACTION_END_T:
+ if (!seg6_bpf_has_valid_srh(skb))
+ return -EBADMSG;
+ if (param_len != sizeof(int))
+ return -EINVAL;
+ return seg6_lookup_nexthop(skb, NULL, *(int *)param);
+ case SEG6_LOCAL_ACTION_END_DT6:
+ if (!seg6_bpf_has_valid_srh(skb))
+ return -EBADMSG;
if (param_len != sizeof(int))
return -EINVAL;
+
+ // find inner IPv6 header, pull outer IPv6 header
+ if (ipv6_find_hdr(skb, &hdroff, IPPROTO_IPV6, NULL, NULL) < 0)
+ return -EBADMSG;
+ if (!pskb_pull(skb, hdroff))
+ return -EBADMSG;
+
+ skb_postpull_rcsum(skb, skb_network_header(skb), hdroff);
+ skb_reset_network_header(skb);
+ skb_reset_transport_header(skb);
+ skb->encapsulation = 0;
+
+ bpf_compute_data_pointers(skb);
+ bpf_update_srh_state(skb);
return seg6_lookup_nexthop(skb, NULL, *(int *)param);
case SEG6_LOCAL_ACTION_END_B6:
+ if (srh_state->srh && !seg6_bpf_has_valid_srh(skb))
+ return -EBADMSG;
err = bpf_push_seg6_encap(skb, BPF_LWT_ENCAP_SEG6_INLINE,
param, param_len);
if (!err)
- srh_state->hdrlen =
- ((struct ipv6_sr_hdr *)param)->hdrlen << 3;
+ bpf_update_srh_state(skb);
+
return err;
case SEG6_LOCAL_ACTION_END_B6_ENCAP:
+ if (srh_state->srh && !seg6_bpf_has_valid_srh(skb))
+ return -EBADMSG;
err = bpf_push_seg6_encap(skb, BPF_LWT_ENCAP_SEG6,
param, param_len);
if (!err)
- srh_state->hdrlen =
- ((struct ipv6_sr_hdr *)param)->hdrlen << 3;
+ bpf_update_srh_state(skb);
+
return err;
default:
return -EINVAL;
@@ -4644,15 +4673,14 @@ BPF_CALL_3(bpf_lwt_seg6_adjust_srh, struct sk_buff *, skb, u32, offset,
{
struct seg6_bpf_srh_state *srh_state =
this_cpu_ptr(&seg6_bpf_srh_states);
+ struct ipv6_sr_hdr *srh = srh_state->srh;
void *srh_end, *srh_tlvs, *ptr;
- struct ipv6_sr_hdr *srh;
struct ipv6hdr *hdr;
int srhoff = 0;
int ret;
- if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
+ if (unlikely(srh == NULL))
return -EINVAL;
- srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
srh_tlvs = (void *)((unsigned char *)srh + sizeof(*srh) +
((srh->first_segment + 1) << 4));
@@ -4682,8 +4710,11 @@ BPF_CALL_3(bpf_lwt_seg6_adjust_srh, struct sk_buff *, skb, u32, offset,
hdr = (struct ipv6hdr *)skb->data;
hdr->payload_len = htons(skb->len - sizeof(struct ipv6hdr));
+ if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
+ return -EINVAL;
+ srh_state->srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
srh_state->hdrlen += len;
- srh_state->valid = 0;
+ srh_state->valid = false;
return 0;
}
diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index e1025b493a18..60325dbfe88b 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -459,36 +459,57 @@ static int input_action_end_b6_encap(struct sk_buff *skb,
DEFINE_PER_CPU(struct seg6_bpf_srh_state, seg6_bpf_srh_states);
+bool seg6_bpf_has_valid_srh(struct sk_buff *skb)
+{
+ struct seg6_bpf_srh_state *srh_state =
+ this_cpu_ptr(&seg6_bpf_srh_states);
+ struct ipv6_sr_hdr *srh = srh_state->srh;
+
+ if (unlikely(srh == NULL))
+ return false;
+
+ if (unlikely(!srh_state->valid)) {
+ if ((srh_state->hdrlen & 7) != 0)
+ return false;
+
+ srh->hdrlen = (u8)(srh_state->hdrlen >> 3);
+ if (!seg6_validate_srh(srh, (srh->hdrlen + 1) << 3))
+ return false;
+
+ srh_state->valid = true;
+ }
+
+ return true;
+}
+
static int input_action_end_bpf(struct sk_buff *skb,
struct seg6_local_lwt *slwt)
{
struct seg6_bpf_srh_state *srh_state =
this_cpu_ptr(&seg6_bpf_srh_states);
- struct seg6_bpf_srh_state local_srh_state;
struct ipv6_sr_hdr *srh;
- int srhoff = 0;
int ret;
srh = get_and_validate_srh(skb);
- if (!srh)
- goto drop;
+ if (!srh) {
+ kfree_skb(skb);
+ return -EINVAL;
+ }
advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
/* preempt_disable is needed to protect the per-CPU buffer srh_state,
* which is also accessed by the bpf_lwt_seg6_* helpers
*/
preempt_disable();
+ srh_state->srh = srh;
srh_state->hdrlen = srh->hdrlen << 3;
- srh_state->valid = 1;
+ srh_state->valid = true;
rcu_read_lock();
bpf_compute_data_pointers(skb);
ret = bpf_prog_run_save_cb(slwt->bpf.prog, skb);
rcu_read_unlock();
- local_srh_state = *srh_state;
- preempt_enable();
-
switch (ret) {
case BPF_OK:
case BPF_REDIRECT:
@@ -500,24 +521,17 @@ static int input_action_end_bpf(struct sk_buff *skb,
goto drop;
}
- if (unlikely((local_srh_state.hdrlen & 7) != 0))
- goto drop;
-
- if (ipv6_find_hdr(skb, &srhoff, IPPROTO_ROUTING, NULL, NULL) < 0)
- goto drop;
- srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
- srh->hdrlen = (u8)(local_srh_state.hdrlen >> 3);
-
- if (!local_srh_state.valid &&
- unlikely(!seg6_validate_srh(srh, (srh->hdrlen + 1) << 3)))
+ if (srh_state->srh && !seg6_bpf_has_valid_srh(skb))
goto drop;
+ preempt_enable();
if (ret != BPF_REDIRECT)
seg6_lookup_nexthop(skb, NULL, 0);
return dst_input(skb);
drop:
+ preempt_enable();
kfree_skb(skb);
return -EINVAL;
}
--
2.16.1
^ permalink raw reply related
* Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue
From: Yafang Shao @ 2018-07-26 1:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Eric Dumazet, netdev, LKML
In-Reply-To: <CALOAHbASvcEdudqpit-c=RRZ8xVD+G+0jU-ynp9PsH4_mU7xjw@mail.gmail.com>
On Wed, Jul 25, 2018 at 9:59 PM, Yafang Shao <laoar.shao@gmail.com> wrote:
> On Wed, Jul 25, 2018 at 9:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>> On 07/25/2018 06:40 AM, Yafang Shao wrote:
>>
>>>
>>> Because we want to know why packets were dropped.
>>> If that could be show in netstat, we could easily find that it is
>>> dropped due to ofo prune.
>>
>>
>> We have a counter already for these events : LINUX_MIB_OFOPRUNED
>>
>> You want to add another counter tracking number of _skbs_,
>> which has no precise value for user,
>> given each skb can contain a variable number of _packets_.
>>
>
> Got it.
>
> But with LINUX_MIB_OFOPRUNED, we only know tcp_prune_ofo_queue is
> called, but have no idea how many skbs are dropped.
>
Hi Eric,
LINUX_MIB_TCPOFOQUEUE, LINUX_MIB_TCPOFODROP and LINUX_MIB_TCPOFOMERGE
are all for the number of SKBs, but only LINUX_MIB_OFOPRUNED is for
the event, that could lead misunderstading.
So I think introducing a counter for the number of SKB pruned could be
better, that could help us to track the whole behavior of ofo queue.
That is why I submit this patch.
Thanks
Yafang
^ 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