* [net-next 11/13] net/mlx5e: RX, Prefetch the xdp_frame data area
From: Saeed Mahameed @ 2018-07-26 22:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tariq Toukan, Saeed Mahameed
In-Reply-To: <20180726225647.11926-1-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
A loaded XDP program might write to the xdp_frame data area,
prefetchw() it to avoid a potential cache miss.
Performance tests:
ConnectX-5, XDP_TX packet rate, single ring.
CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
Before: 13,172,976 pps
After: 13,456,248 pps
2% gain.
Fixes: 22f453988194 ("net/mlx5e: Support XDP over Striding RQ")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index e33ca03b2100..15d8ae28c040 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -1099,6 +1099,7 @@ mlx5e_skb_from_cqe_mpwrq_linear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wi,
dma_sync_single_range_for_cpu(rq->pdev, di->addr, head_offset,
frag_size, DMA_FROM_DEVICE);
+ prefetchw(va); /* xdp_frame data area */
prefetch(data);
rcu_read_lock();
--
2.17.0
^ permalink raw reply related
* [net-next 12/13] net/mlx5e: TX, Move DB fields in TXQ-SQ struct
From: Saeed Mahameed @ 2018-07-26 22:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tariq Toukan, Saeed Mahameed
In-Reply-To: <20180726225647.11926-1-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Pointers in DB are static, move them to read-only area so they
do not share a cacheline with fields modified in datapath.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 3f21cafe6be3..c41cfc2a4b70 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -365,16 +365,14 @@ struct mlx5e_txqsq {
struct mlx5e_cq cq;
- /* write@xmit, read@completion */
- struct {
- struct mlx5e_sq_dma *dma_fifo;
- struct mlx5e_tx_wqe_info *wqe_info;
- } db;
-
/* read only */
struct mlx5_wq_cyc wq;
u32 dma_fifo_mask;
struct mlx5e_sq_stats *stats;
+ struct {
+ struct mlx5e_sq_dma *dma_fifo;
+ struct mlx5e_tx_wqe_info *wqe_info;
+ } db;
void __iomem *uar_map;
struct netdev_queue *txq;
u32 sqn;
--
2.17.0
^ permalink raw reply related
* [net-next 13/13] net/mlx5e: TX, Use function to access sq_dma object in fifo
From: Saeed Mahameed @ 2018-07-26 22:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tariq Toukan, Saeed Mahameed
In-Reply-To: <20180726225647.11926-1-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Use designated function mlx5e_dma_get() to get
the mlx5e_sq_dma object to be pushed into fifo.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/en_tx.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
index 9106ea45e3cb..ae73ea992845 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
@@ -66,22 +66,21 @@ static inline void mlx5e_tx_dma_unmap(struct device *pdev,
}
}
+static inline struct mlx5e_sq_dma *mlx5e_dma_get(struct mlx5e_txqsq *sq, u32 i)
+{
+ return &sq->db.dma_fifo[i & sq->dma_fifo_mask];
+}
+
static inline void mlx5e_dma_push(struct mlx5e_txqsq *sq,
dma_addr_t addr,
u32 size,
enum mlx5e_dma_map_type map_type)
{
- u32 i = sq->dma_fifo_pc & sq->dma_fifo_mask;
+ struct mlx5e_sq_dma *dma = mlx5e_dma_get(sq, sq->dma_fifo_pc++);
- sq->db.dma_fifo[i].addr = addr;
- sq->db.dma_fifo[i].size = size;
- sq->db.dma_fifo[i].type = map_type;
- sq->dma_fifo_pc++;
-}
-
-static inline struct mlx5e_sq_dma *mlx5e_dma_get(struct mlx5e_txqsq *sq, u32 i)
-{
- return &sq->db.dma_fifo[i & sq->dma_fifo_mask];
+ dma->addr = addr;
+ dma->size = size;
+ dma->type = map_type;
}
static void mlx5e_dma_unmap_wqe_err(struct mlx5e_txqsq *sq, u8 num_dma)
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] bpf: verifier: BPF_MOV don't mark dst reg if src == dst
From: Y Song @ 2018-07-26 23:21 UTC (permalink / raw)
To: Arthur Fabre; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <CAOn4ftsOedWzGNRHb2RhkADJh-qBFNLPoH89MUsZxxZri52_Tg@mail.gmail.com>
On Thu, Jul 26, 2018 at 9:52 AM, Arthur Fabre <afabre@cloudflare.com> wrote:
> Oops, gmail seems to have mangled everything. Will resend using git
> send-email.
>
> I've added the test cases for mov64, but I'm not sure of the expected mov32
> behavior.
The interpreter has below:
ALU_MOV_X:
DST = (u32) SRC;
CONT;
...
ALU64_MOV_X:
DST = SRC;
CONT;
The later verifier code does seem to mark dst_reg properly for both
ALU and ALU64.
> Currently coerce_reg_to_size() is called after mark_reg_unknown(),
> which sets the bounds to 64bits. coerce_reg_to_size() resets the bounds
> again,
> as they're too "wide" to fit the new size. It sets SMIN = UMIN = 0,
> which seems weird. Shouldn't SMIN be 1 << (size * 8 - 1)? Same applies for
> SMAX.
The SMIN/UMIN still should be 0 since there is no negative here due to
smaller width?
> Should mov32 always mark the dst as unbounded?
We can do better than unbounded for dst register of mov32, which is
the code already
doing?
>
>
> On Thu, Jul 26, 2018 at 1:42 AM, Daniel Borkmann <daniel@iogearbox.net>
> wrote:
>>
>> On 07/26/2018 12:08 AM, Arthur Fabre wrote:
>> > 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.
Could you explain (and add to the commit messages eventually) what
are these unexpected errors?
>> >
>> > 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;
>> >
>>
>> Thanks a lot for the patch! Looks like it's corrupted wrt newline.
>>
>> Please also add test cases to tools/testing/selftests/bpf/test_verifier.c
>> for the cases of mov64 and mov32 where in each src==dst and src!=dst;
>> mov32
>> should mark it as unbounded but not former, so would be good to keep
>> tracking
>> that in selftests.
>
>
^ permalink raw reply
* Re: [PATCH net-next v3 4/5] net/tc: introduce TC_ACT_REINJECT.
From: Cong Wang @ 2018-07-26 23:25 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Marcelo Ricardo Leitner, Paolo Abeni,
Linux Kernel Network Developers, Jiri Pirko, Daniel Borkmann,
Eyal Birger, David Miller
In-Reply-To: <af5b5136-3b42-7f14-ffe9-d8f060562fa6@mojatatu.com>
On Thu, Jul 26, 2018 at 5:52 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> On 25/07/18 01:09 PM, Marcelo Ricardo Leitner wrote:
> > On Wed, Jul 25, 2018 at 09:48:16AM -0700, Cong Wang wrote:
> >> On Wed, Jul 25, 2018 at 5:27 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >>>
> >>> Those changes were there from the beginning (above patch did
> >>> not introduce them).
> >>> IIRC, the reason was to distinguish between policy intended
> >>> drops and drops because of errors.
> >>
> >> There must be a limit for "overlimit" to make sense. There is
> >> no limit in mirred action's context, probably there is only
> >> such a limit in act_police. So, all rest should not touch overlimit.
> >
> > +1
> >
>
> I agree we should at least record drop count(unrelated patch though).
> we should keep overlimit (for no other reason other than this
> has been around for at least 15 years).
>
> On why "overlimit"? It is just a name for a counter that is useless
> for most actions (but was still being transfered to user space).
> It is the closest counter to counting "this failed because of
> runtime errors" as opposed to "user asked us to drop this".
>
> Probably a good alternative is to make a very small stats v3 structure
> (we have migrated stats structures before) and extend for
> each action/classifier/qdisc to add its extra counters using XSTATS.
Agreed.
>
> Note:
> If you are _mirroring_ packets - incrementing the drop counter is
> misleading because the packet is not dropped by the system.
> i.e the qdisc will not record it as dropped; it should for
> redirect policy. It is useful to be able to tell
> them apart when you are collecting analytics just for actions.
Sounds like we just need another counter rather than re-using overlimit
or drops.
> (if youve worked on a massive amount of machines you'll appreciate
> being able to debug by looking at counters that reduce ambiguity).
>
Yes, this is how I found out the overlimit of htb qdisc is inaccurate
or misleading, instead the one in htb class is accurate, see:
commit 3c75f6ee139d464351f8ab77a042dd3635769d98
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Sep 18 12:36:22 2017 -0700
net_sched: sch_htb: add per class overlimits counter
^ permalink raw reply
* Re: [PATCH net-next v4 4/4] act_mirred: use TC_ACT_REINSERT when possible
From: Cong Wang @ 2018-07-26 23:27 UTC (permalink / raw)
To: Paolo Abeni
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
Daniel Borkmann, Marcelo Ricardo Leitner, Eyal Birger,
David Miller
In-Reply-To: <5d417f3968ffb75b4cd3a44bc8ffca2a6d85f100.1532611319.git.pabeni@redhat.com>
On Thu, Jul 26, 2018 at 7:35 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> When mirred is invoked from the ingress path, and it wants to redirect
> the processed packet, it can now use the TC_ACT_REINSERT action,
> filling the tcf_result accordingly, and avoiding a per packet
> skb_clone().
>
> Overall this gives a ~10% improvement in forwarding performance for the
> TC S/W data path and TC S/W performances are now comparable to the
> kernel openvswitch datapath.
>
> v1 -> v2: use ACT_MIRRED instead of ACT_REDIRECT
> v2 -> v3: updated after action rename, fixed typo into the commit
> message
> v3 -> v4: updated again after action rename, added more comments to
> the code (JiriP), skip the optimization if the control action
> need to touch the tcf_result (Paolo)
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Overall it looks good to me now.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v4 3/4] net/tc: introduce TC_ACT_REINSERT.
From: Cong Wang @ 2018-07-26 23:29 UTC (permalink / raw)
To: Paolo Abeni
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
Daniel Borkmann, Marcelo Ricardo Leitner, Eyal Birger,
David Miller
In-Reply-To: <9f1f9426acce7764e0376a1bcfb44b49f6e15eb3.1532611319.git.pabeni@redhat.com>
On Thu, Jul 26, 2018 at 7:35 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> This is similar TC_ACT_REDIRECT, but with a slightly different
> semantic:
> - on ingress the mirred skbs are passed to the target device
> network stack without any additional check not scrubbing.
> - the rcu-protected stats provided via the tcf_result struct
> are updated on error conditions.
>
> This new tcfa_action value is not exposed to the user-space
> and can be used only internally by clsact.
>
> v1 -> v2: do not touch TC_ACT_REDIRECT code path, introduce
> a new action type instead
>
> v2 -> v3:
> - rename the new action value TC_ACT_REINJECT, update the
> helper accordingly
> - take care of uncloned reinjected packets in XDP generic
> hook
>
> v3 -> v4:
> - renamed again the new action value (JiriP)
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> Note: this patch still touch only overlimits, even there is some
> agreement to touch (also) drops on reinsert/mirred failure, but
> such change is independent to this series
Totally agree.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion.
From: NeilBrown @ 2018-07-27 1:04 UTC (permalink / raw)
To: paulmck; +Cc: Herbert Xu, Thomas Graf, netdev, linux-kernel
In-Reply-To: <20180725152250.GN12945@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 461 bytes --]
On Wed, Jul 25 2018, Paul E. McKenney wrote:
>>
>> Looks good ... except ... naming is hard.
>>
>> is_after_call_rcu_init() asserts where in the lifecycle we are,
>> is_after_call_rcu() tests where in the lifecycle we are.
>>
>> The names are similar but the purpose is quite different.
>> Maybe s/is_after_call_rcu_init/call_rcu_init/ ??
>
> How about rcu_head_init() and rcu_head_after_call_rcu()?
Yes, I like those.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next 0/4] samples: bpf: convert two more samples to libbpf
From: Y Song @ 2018-07-26 23:57 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Alexei Starovoitov, Daniel Borkmann, oss-drivers, netdev
In-Reply-To: <20180726213221.1295-1-jakub.kicinski@netronome.com>
On Thu, Jul 26, 2018 at 2:32 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> Hi!
>
> This set converts xdpsock_user.c and xdp_fwd_user.c to use libbpf instead
> of bpf_load.o. First two patches are minor improvements to libbpf to make
> the conversion (and use of libbpf in general) nicer.
>
> Jakub Kicinski (4):
> tools: libbpf: handle NULL program gracefully in bpf_program__nth_fd()
> tools: libbpf: add bpf_object__find_program_by_title()
> samples: bpf: convert xdp_fwd_user.c to libbpf
> samples: bpf: convert xdpsock_user.c to libbpf
LGTM. Ack for the whole series.
Acked-by: Yonghong Song <yhs@fb.com>
>
> samples/bpf/Makefile | 4 ++--
> samples/bpf/xdp_fwd_user.c | 34 +++++++++++++++++++++++-----------
> samples/bpf/xdpsock_user.c | 38 +++++++++++++++++++++++++++++---------
> tools/lib/bpf/libbpf.c | 15 +++++++++++++++
> tools/lib/bpf/libbpf.h | 3 +++
> 5 files changed, 72 insertions(+), 22 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next] tools/bpftool: ignore build products
From: Daniel Borkmann @ 2018-07-27 1:47 UTC (permalink / raw)
To: Taeung Song, Alexei Starovoitov; +Cc: netdev, linux-kernel
In-Reply-To: <20180725063651.19743-1-treeze.taeung@gmail.com>
On 07/25/2018 08:36 AM, Taeung Song wrote:
> For untracked things of tools/bpf, add this.
>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Applied to bpf-next, thanks Taeung!
^ permalink raw reply
* Re: [BUG BISECT] NFSv4 client fails on Flush Journal to Persistent Storage
From: Chuck Lever @ 2018-07-27 1:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Trond Myklebust, sudeep.holla@arm.com, Trond Myklebust,
Anna Schumaker, Bruce Fields, Jeff Layton, David S. Miller,
Linux NFS Mailing List, netdev, linux-kernel,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <CAJKOXPejStfaQdtUwh33v+aC7KpamoLkix3nitbHrDRx4QAR6g@mail.gmail.com>
> On Jul 26, 2018, at 4:46 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 25 July 2018 at 16:31, Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>>
>>> On Jul 25, 2018, at 9:27 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>> On 18 June 2018 at 18:20, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>
>>>> The extra serialization appears to have a reproducible performance
>>>> impact on RDMA, which no longer takes the reserve_lock when allocating
>>>> a slot.
>>>>
>>>> I could put an xprt_alloc_xid call in xprt_alloc_slot, but that would
>>>> only work for socket-based transports. Would it be OK if RDMA had its
>>>> own XID allocation mechanism?
>>>
>>> Hi,
>>>
>>> On recent next the issue appeared again. My boards with NFSv4 root
>>> timeout on 80% of boots. This time my NFS server is faster - Pi3 B+
>>> :).
>>>
>>> Is this know? Should I start long bisect or maybe you can point me to
>>> possible causes?
>>
>> Hi Krzysztof, I don't know of any recent changes. Bisecting would be
>> a good place to start.
>
> Hi,
>
> That was my mistake because of missing part of NFS server
> configuration on new board. I tested again recent releases and current
> linux-next and everything works fine.
>
> Sorry for the noise.
Thanks for the update.
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH net-next v4 1/4] net/sched: user-space can't set unknown tcfa_action values
From: Marcelo Ricardo Leitner @ 2018-07-27 0:28 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, Jamal Hadi Salim, Cong Wang, Jiri Pirko, Daniel Borkmann,
Eyal Birger, David S. Miller
In-Reply-To: <2717eb1db9f7b89905809d00391bdab2ad123c00.1532611319.git.pabeni@redhat.com>
Hi,
On Thu, Jul 26, 2018 at 04:34:57PM +0200, Paolo Abeni wrote:
...
> @@ -895,6 +904,14 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
> }
> }
>
> + if (!tcf_action_valid(a->tcfa_action)) {
> + net_warn_ratelimited("invalid %d action value, using "
> + "TC_ACT_UNSPEC instead", a->tcfa_action);
Now that it is reporting the error via extack, do we really need this
warn net_warn?
extack will be shown as a warning by iproute2 even if the command
succeeds.
> + NL_SET_ERR_MSG(extack, "invalid action value, using "
> + "TC_ACT_UNSPEC instead");
Quoted strings shouldn't be broken down into multiple lines..
> + a->tcfa_action = TC_ACT_UNSPEC;
> + }
> +
> return a;
>
> err_mod:
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next] samples/bpf: xdpsock: order memory on AArch64
From: Daniel Borkmann @ 2018-07-27 1:48 UTC (permalink / raw)
To: Brian Brooks, ast, bjorn.topel, magnus.karlsson; +Cc: netdev, linux-kernel
In-Reply-To: <20180725210819.1458-1-brian.brooks@linaro.org>
On 07/25/2018 11:08 PM, Brian Brooks wrote:
> Define u_smp_rmb() and u_smp_wmb() to respective barrier instructions.
> This ensures the processor will order accesses to queue indices against
> accesses to queue ring entries.
>
> Signed-off-by: Brian Brooks <brian.brooks@linaro.org>
Applied to bpf-next, thanks Brian!
^ permalink raw reply
* Re: [PATCH bpf-next v2] samples/bpf: Add BTF build flags to Makefile
From: Daniel Borkmann @ 2018-07-27 1:51 UTC (permalink / raw)
To: Taeung Song, Alexei Starovoitov; +Cc: netdev, linux-kernel, Jakub Kicinski
In-Reply-To: <20180726101344.19351-1-treeze.taeung@gmail.com>
On 07/26/2018 12:13 PM, 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")
>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Applied to bpf-next, thanks Taeung!
^ permalink raw reply
* [PATCH net-next] net: hns: make hns_dsaf_roce_reset non static
From: YueHaibing @ 2018-07-27 1:53 UTC (permalink / raw)
To: davem, yisen.zhuang, salil.mehta
Cc: linux-kernel, netdev, linyunsheng, matthias.bgg, lipeng321,
YueHaibing
hns_dsaf_roce_reset is exported and used in hns_roce_hw_v1.c
In commit 336a443bd9dd ("net: hns: Make many functions static") I make
it static wrongly.
drivers/infiniband/hw/hns/hns_roce_hw_v1.o: In function `hns_roce_v1_reset':
hns_roce_hw_v1.c:(.text+0x37ac): undefined reference to `hns_dsaf_roce_reset'
hns_roce_hw_v1.c:(.text+0x37cc): undefined reference to `hns_dsaf_roce_reset'
Fixes: 336a443bd9dd ("net: hns: Make many functions static")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 7afc675..619e6ce 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2836,7 +2836,7 @@ module_platform_driver(g_dsaf_driver);
* @enable: false - request reset , true - drop reset
* retuen 0 - success , negative -fail
*/
-static int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset)
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, bool dereset)
{
struct dsaf_device *dsaf_dev;
struct platform_device *pdev;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH v5 bpf-next 3/9] veth: Avoid drops by oversized packets when XDP is enabled
From: Jakub Kicinski @ 2018-07-27 0:51 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180726144032.2116-4-toshiaki.makita1@gmail.com>
On Thu, 26 Jul 2018 23:40:26 +0900, Toshiaki Makita wrote:
> + max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
> + peer->hard_header_len -
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> + if (peer->mtu > max_mtu) {
> + NL_SET_ERR_MSG_MOD(extack, "Peer MTU is too large to set XDP");
> + err = -ERANGE;
> + goto err;
> + }
You need to add .ndo_change_mtu and check this condition there too.
^ permalink raw reply
* Re: [PATCH v2] perf build: Build error in libbpf with EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
From: Daniel Borkmann @ 2018-07-27 2:16 UTC (permalink / raw)
To: Jakub Kicinski, Thomas Richter
Cc: ast, netdev, linux-kernel, heiko.carstens, brueckner, schwidefsky,
wangnan0
In-Reply-To: <20180725184835.5d37bef4@cakuba.netronome.com>
On 07/26/2018 03:48 AM, Jakub Kicinski wrote:
> On Wed, 25 Jul 2018 09:21:26 +0200, Thomas Richter wrote:
>> commit a5b8bd47dcc57 ("bpf tools: Collect eBPF programs from their own sections")
>
> Hmm.. are you sure it's not 531b014e7a2f ("tools: bpf: make use of
> reallocarray") that caused the issue? That commit made us switch from
> XSI-compliant to GNU-specific strerror_r() implementation..
>
> /me checks
>
> Yes it looks like 531b014e7a2f~ builds just fine.
>
> Daniel, did you try to apply v1 to the bpf tree? Perhaps there is a
> confusion about the trees here, if this is caused by my recent change
> it's a bpf-next material. strerror() works, but strerror_r() seems
> nicer, so perhaps we could keep it if the patch worked in bpf-next?
Yeah indeed, the issue is only in bpf-next. When I compile libbpf from
bpf tree with the below flags then it's all good.
Agree that we should rather use strerror_r() given this is a library.
>> causes a compiler error when building the perf tool in the linux-next tree.
>> I compile it using a FEDORA 28 installation, my gcc compiler version:
>> gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
>>
>> The file that causes the error is tools/lib/bpf/libbpf.c
>>
>> Here is the error message:
[...]
>> @@ -2334,7 +2331,7 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
>> __u64 data_tail = header->data_tail;
>> __u64 data_head = header->data_head;
>> void *base, *begin, *end;
>> - int ret;
>> + int ret = 0;
>>
>> asm volatile("" ::: "memory"); /* in real code it should be smp_rmb() */
>> if (data_head == data_tail)
>
> This looks like a separate issue. The ret variable should really be
> enum bpf_perf_event_ret, so could you please initialize it to one of the
> values of this enum?
>
> The uninitilized condition can only happen if (data_head != data_tail)
> but at the same time (data_head % size == data_tail % size) which
> should never really happen... Perhaps initializing to
> LIBBPF_PERF_EVENT_ERROR would make sense?
>
> Or better still adding:
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index f732237610e5..fa5a25945f19 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -2289,6 +2289,8 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
>
> begin = base + data_tail % size;
> end = base + data_head % size;
> + if (being == end)
> + return LIBBPF_PERF_EVENT_ERROR;
Sounds good to me.
> while (begin != end) {
> struct perf_event_header *ehdr;
>
^ permalink raw reply
* Re: [PATCH v5 bpf-next 3/9] veth: Avoid drops by oversized packets when XDP is enabled
From: Toshiaki Makita @ 2018-07-27 1:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180726175127.075185fc@cakuba.netronome.com>
On 2018/07/27 9:51, Jakub Kicinski wrote:
> On Thu, 26 Jul 2018 23:40:26 +0900, Toshiaki Makita wrote:
>> + max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
>> + peer->hard_header_len -
>> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> + if (peer->mtu > max_mtu) {
>> + NL_SET_ERR_MSG_MOD(extack, "Peer MTU is too large to set XDP");
>> + err = -ERANGE;
>> + goto err;
>> + }
>
> You need to add .ndo_change_mtu and check this condition there too.
I'm setting peer->max_mtu so no need to add .ndo_change_mtu.
Inappropriate MTU will be refused in dev_set_mtu().
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH v5 bpf-next 3/9] veth: Avoid drops by oversized packets when XDP is enabled
From: Jakub Kicinski @ 2018-07-27 1:08 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <aa000680-a097-cd1a-e4ab-aacf9d172b04@lab.ntt.co.jp>
On Fri, 27 Jul 2018 10:06:41 +0900, Toshiaki Makita wrote:
> On 2018/07/27 9:51, Jakub Kicinski wrote:
> > On Thu, 26 Jul 2018 23:40:26 +0900, Toshiaki Makita wrote:
> >> + max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
> >> + peer->hard_header_len -
> >> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> >> + if (peer->mtu > max_mtu) {
> >> + NL_SET_ERR_MSG_MOD(extack, "Peer MTU is too large to set XDP");
> >> + err = -ERANGE;
> >> + goto err;
> >> + }
> >
> > You need to add .ndo_change_mtu and check this condition there too.
>
> I'm setting peer->max_mtu so no need to add .ndo_change_mtu.
> Inappropriate MTU will be refused in dev_set_mtu().
missed that, sorry
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the rdma tree
From: Stephen Rothwell @ 2018-07-27 2:33 UTC (permalink / raw)
To: David Miller, Networking, Doug Ledford, Jason Gunthorpe
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Parav Pandit,
Ursula Braun, Leon Romanovsky
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got conflicts in:
net/smc/smc_core.c
net/smc/smc_ib.c
between commit:
ddb457c6993b ("net/smc: Replace ib_query_gid with rdma_get_gid_attr")
from the rdma tree and commit:
7005ada68d17 ("net/smc: use correct vlan gid of RoCE device")
(and maybe others)
from the net-next tree.
I fixed it up (I wasn't sure how to fix this up as so much has changed
in the net-next tree and both modified functions had been (re)moved,
so I effectively reverted the rdma tree commit) and can carry the fix
as necessary. Please come to some arrangement about this.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] isdn: mISDN: hfcpci: Replace GFP_ATOMIC with GFP_KERNEL in hfc_probe()
From: Jia-Ju Bai @ 2018-07-27 2:39 UTC (permalink / raw)
To: isdn, keescook, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
hfc_probe() is never called in atomic context.
It calls kzalloc() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/isdn/hardware/mISDN/hfcpci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c b/drivers/isdn/hardware/mISDN/hfcpci.c
index 34c93874af23..5a2e2455761f 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -2219,7 +2219,7 @@ hfc_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
struct hfc_pci *card;
struct _hfc_map *m = (struct _hfc_map *)ent->driver_data;
- card = kzalloc(sizeof(struct hfc_pci), GFP_ATOMIC);
+ card = kzalloc(sizeof(struct hfc_pci), GFP_KERNEL);
if (!card) {
printk(KERN_ERR "No kmem for HFC card\n");
return err;
--
2.17.0
^ permalink raw reply related
* [PATCH] isdn: mISDN: netjet: Replace GFP_ATOMIC with GFP_KERNEL in nj_probe()
From: Jia-Ju Bai @ 2018-07-27 2:41 UTC (permalink / raw)
To: isdn, keescook, jeyu; +Cc: netdev, linux-kernel, Jia-Ju Bai
nj_probe() is never called in atomic context.
It calls kzalloc() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/isdn/hardware/mISDN/netjet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/netjet.c b/drivers/isdn/hardware/mISDN/netjet.c
index 89d9ba8ed535..2b317cb63d06 100644
--- a/drivers/isdn/hardware/mISDN/netjet.c
+++ b/drivers/isdn/hardware/mISDN/netjet.c
@@ -1084,7 +1084,7 @@ nj_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return -ENODEV;
}
- card = kzalloc(sizeof(struct tiger_hw), GFP_ATOMIC);
+ card = kzalloc(sizeof(struct tiger_hw), GFP_KERNEL);
if (!card) {
pr_info("No kmem for Netjet\n");
return err;
--
2.17.0
^ permalink raw reply related
* [PATCH] isdn: hisax: callc: Replace GFP_ATOMIC with GFP_KERNEL in init_PStack()
From: Jia-Ju Bai @ 2018-07-27 2:45 UTC (permalink / raw)
To: isdn; +Cc: netdev, linux-kernel, Jia-Ju Bai
init_PStack() is never called in atomic context.
It calls kmalloc() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/isdn/hisax/callc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hisax/callc.c b/drivers/isdn/hisax/callc.c
index ddec47a911a0..0faecb723f13 100644
--- a/drivers/isdn/hisax/callc.c
+++ b/drivers/isdn/hisax/callc.c
@@ -1012,7 +1012,7 @@ dummy_pstack(struct PStack *st, int pr, void *arg) {
static int
init_PStack(struct PStack **stp) {
- *stp = kmalloc(sizeof(struct PStack), GFP_ATOMIC);
+ *stp = kmalloc(sizeof(struct PStack), GFP_KERNEL);
if (!*stp)
return -ENOMEM;
(*stp)->next = NULL;
--
2.17.0
^ permalink raw reply related
* [PATCH] isdn: hisax: config: Replace GFP_ATOMIC with GFP_KERNEL
From: Jia-Ju Bai @ 2018-07-27 2:48 UTC (permalink / raw)
To: isdn; +Cc: netdev, linux-kernel, Jia-Ju Bai
hisax_cs_new() and hisax_cs_setup() are never called in atomic context.
They call kmalloc() and kzalloc() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/isdn/hisax/config.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index 7108bdb8742e..b14714004503 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -1029,7 +1029,7 @@ static int hisax_cs_new(int cardnr, char *id, struct IsdnCard *card,
*cs_out = NULL;
- cs = kzalloc(sizeof(struct IsdnCardState), GFP_ATOMIC);
+ cs = kzalloc(sizeof(struct IsdnCardState), GFP_KERNEL);
if (!cs) {
printk(KERN_WARNING
"HiSax: No memory for IsdnCardState(card %d)\n",
@@ -1059,12 +1059,12 @@ static int hisax_cs_new(int cardnr, char *id, struct IsdnCard *card,
"HiSax: Card Type %d out of range\n", card->typ);
goto outf_cs;
}
- if (!(cs->dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
+ if (!(cs->dlog = kmalloc(MAX_DLOG_SPACE, GFP_KERNEL))) {
printk(KERN_WARNING
"HiSax: No memory for dlog(card %d)\n", cardnr + 1);
goto outf_cs;
}
- if (!(cs->status_buf = kmalloc(HISAX_STATUS_BUFSIZE, GFP_ATOMIC))) {
+ if (!(cs->status_buf = kmalloc(HISAX_STATUS_BUFSIZE, GFP_KERNEL))) {
printk(KERN_WARNING
"HiSax: No memory for status_buf(card %d)\n",
cardnr + 1);
@@ -1123,7 +1123,7 @@ static int hisax_cs_setup(int cardnr, struct IsdnCard *card,
{
int ret;
- if (!(cs->rcvbuf = kmalloc(MAX_DFRAME_LEN_L1, GFP_ATOMIC))) {
+ if (!(cs->rcvbuf = kmalloc(MAX_DFRAME_LEN_L1, GFP_KERNEL))) {
printk(KERN_WARNING "HiSax: No memory for isac rcvbuf\n");
ll_unload(cs);
goto outf_cs;
--
2.17.0
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the rdma tree
From: Jason Gunthorpe @ 2018-07-27 2:48 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Doug Ledford, Linux-Next Mailing List,
Linux Kernel Mailing List, Parav Pandit, Ursula Braun,
Leon Romanovsky, linux-rdma
In-Reply-To: <20180727123301.3ac97ddc@canb.auug.org.au>
On Fri, Jul 27, 2018 at 12:33:01PM +1000, Stephen Rothwell wrote:
> I fixed it up (I wasn't sure how to fix this up as so much has changed
> in the net-next tree and both modified functions had been (re)moved,
> so I effectively reverted the rdma tree commit) and can carry the fix
> as necessary. Please come to some arrangement about this.
How does that still compile? We removed ib_query_gid() from the rdma
tree and replaced it with rdma_get_gid_attr()..
I think the merge resolution is going to be a bit nasty to absorb
that much changing..
Perhaps we should add a compatability ib_query_gid back to the RDMA
tree and then send DaveM a commit to fix SMC and remove it during the
next cycle? Linus can resolve smc_ib.c by using the net version
Does someone else have a better idea?
Thanks,
Jason
^ 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