From: Daniel Borkmann <daniel@iogearbox.net>
To: Saeed Mahameed <saeedm@mellanox.com>, davem@davemloft.net
Cc: alexei.starovoitov@gmail.com, bblanco@plumgrid.com,
tariqt@mellanox.com, zhiyisun@gmail.com, ranas@mellanox.com,
netdev@vger.kernel.org
Subject: Re: [PATCH net 2/3] bpf, mlx5: fix various refcount/prog issues in mlx5e_xdp_set
Date: Mon, 14 Nov 2016 20:05:56 +0100 [thread overview]
Message-ID: <582A0B14.7080209@iogearbox.net> (raw)
In-Reply-To: <af02aa53-0df6-e8b7-bcfe-5f765f5a8c09@mellanox.com>
On 11/14/2016 07:27 PM, Saeed Mahameed wrote:
> On 11/14/2016 02:43 AM, Daniel Borkmann wrote:
>> There are multiple issues in mlx5e_xdp_set():
>>
>> 1) prog can be NULL, so calling unconditionally into bpf_prog_add(prog,
>> priv->params.num_channels) can end badly.
>
> not correct, if prog is null we will never get to bpf_prog_add:
>
> reset = (!priv->xdp_prog || !prog);
> [...]
> if (!test_bit(MLX5E_STATE_OPENED, &priv->state) || reset)
> goto unlock;
> bpf_prog_add...
Yep, I noticed already, dropped this from the changelog for net-next
rebase anyway.
>> 2) The batched bpf_prog_add() should be done at an earlier point in
>> time. This makes sure that we cannot fail anymore at the time we
>> want to set the program for each channel. This only means that we
>> have to undo the bpf_prog_add() in case we return early due to
>> reset or device not in MLX5E_STATE_OPENED yet. Note, err is 0 here.
>
> It is delayed for a reason, we do delayed batched bpf_prog_add()
> only when reset is not required (exchanging prog/old_prg) when both prog and old_prog are not null,
> which means the only thing that could fail in this case is bpf_prog_add.
Right, plus 3) below.
> so i don't see any reason for changing the logic, checking for bpf_prog_add return value would be sufficient.
Yes, but if that fails, it would be better to check early for bailing out
since at this point in time undoing logic becomes unnecessary ugly.
> Sorry I need to go for now, I will continue reviewing this patch later. but this patch looks a little bit exaggerated.
>
>> 3) When swapping the priv->xdp_prog, then no extra reference count must
>> be taken since we got that from call path via dev_change_xdp_fd()
>> already. Otherwise, we'd never be able to free the program. Also,
>> bpf_prog_add() without checking the return code could fail.
>>
>> Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
next prev parent reply other threads:[~2016-11-14 19:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 0:43 [PATCH net 0/3] Couple of BPF refcount fixes for mlx5 Daniel Borkmann
2016-11-14 0:43 ` [PATCH net 1/3] bpf, mlx5: fix mlx5e_create_rq taking reference on prog Daniel Borkmann
2016-11-14 18:15 ` Saeed Mahameed
2016-11-14 18:26 ` Daniel Borkmann
2016-11-14 0:43 ` [PATCH net 2/3] bpf, mlx5: fix various refcount/prog issues in mlx5e_xdp_set Daniel Borkmann
2016-11-14 2:49 ` Alexei Starovoitov
2016-11-14 8:49 ` Daniel Borkmann
2016-11-14 17:35 ` Alexei Starovoitov
2016-11-14 18:23 ` Daniel Borkmann
2016-11-14 18:27 ` Saeed Mahameed
2016-11-14 19:05 ` Daniel Borkmann [this message]
2016-11-14 0:43 ` [PATCH net 3/3] bpf, mlx5: drop priv->xdp_prog reference on netdev cleanup Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=582A0B14.7080209@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=alexei.starovoitov@gmail.com \
--cc=bblanco@plumgrid.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ranas@mellanox.com \
--cc=saeedm@mellanox.com \
--cc=tariqt@mellanox.com \
--cc=zhiyisun@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.