From: Jesper Dangaard Brouer <brouer@redhat.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: brouer@redhat.com, bpf@vger.kernel.org, bjorn.topel@intel.com,
songliubraving@fb.com, ast@kernel.org, daniel@iogearbox.net,
toke@redhat.com, maciej.fijalkowski@intel.com,
netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/3] bpf: xdp, update devmap comments to reflect napi/rcu usage
Date: Sun, 26 Jan 2020 22:28:07 +0100 [thread overview]
Message-ID: <20200126222807.3f8e2268@carbon> (raw)
In-Reply-To: <1580011133-17784-2-git-send-email-john.fastabend@gmail.com>
On Sat, 25 Jan 2020 19:58:51 -0800
John Fastabend <john.fastabend@gmail.com> wrote:
> Now that we rely on synchronize_rcu and call_rcu waiting to
> exit perempt-disable regions (NAPI) lets update the comments
> to reflect this.
>
> Fixes: 0536b85239b84 ("xdp: Simplify devmap cleanup")
> Acked-by: Björn Töpel <bjorn.topel@intel.com>
> Acked-by: Song Liu <songliubraving@fb.com>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> kernel/bpf/devmap.c | 21 +++++++++++----------
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index da9c832..f0bf525 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -193,10 +193,12 @@ static void dev_map_free(struct bpf_map *map)
>
> /* At this point bpf_prog->aux->refcnt == 0 and this map->refcnt == 0,
> * so the programs (can be more than one that used this map) were
> - * disconnected from events. Wait for outstanding critical sections in
> - * these programs to complete. The rcu critical section only guarantees
> - * no further reads against netdev_map. It does __not__ ensure pending
> - * flush operations (if any) are complete.
> + * disconnected from events. The following synchronize_rcu() guarantees
> + * both rcu read critical sections complete and waits for
> + * preempt-disable regions (NAPI being the relavent context here) so we
^^^^^^^^
Spelling: relevant
I would hate to block the patch this close to the release deadline, so
maybe DaveM can just adjust this before applying?
> + * are certain there will be no further reads against the netdev_map and
> + * all flush operations are complete. Flush operations can only be done
> + * from NAPI context for this reason.
> */
>
> spin_lock(&dev_map_lock);
> @@ -498,12 +500,11 @@ static int dev_map_delete_elem(struct bpf_map *map, void *key)
> return -EINVAL;
>
> /* Use call_rcu() here to ensure any rcu critical sections have
> - * completed, but this does not guarantee a flush has happened
> - * yet. Because driver side rcu_read_lock/unlock only protects the
> - * running XDP program. However, for pending flush operations the
> - * dev and ctx are stored in another per cpu map. And additionally,
> - * the driver tear down ensures all soft irqs are complete before
> - * removing the net device in the case of dev_put equals zero.
> + * completed as well as any flush operations because call_rcu
> + * will wait for preempt-disable region to complete, NAPI in this
> + * context. And additionally, the driver tear down ensures all
> + * soft irqs are complete before removing the net device in the
> + * case of dev_put equals zero.
> */
> old_dev = xchg(&dtab->netdev_map[k], NULL);
> if (old_dev)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2020-01-26 21:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 3:58 [PATCH bpf-next v2 0/3] XDP flush cleanups John Fastabend
2020-01-26 3:58 ` [PATCH bpf-next v2 1/3] bpf: xdp, update devmap comments to reflect napi/rcu usage John Fastabend
2020-01-26 21:28 ` Jesper Dangaard Brouer [this message]
2020-01-26 3:58 ` [PATCH bpf-next v2 2/3] bpf: xdp, virtio_net use access ptr macro for xdp enable check John Fastabend
2020-01-26 21:28 ` Jesper Dangaard Brouer
2020-01-26 3:58 ` [PATCH bpf-next v2 3/3] bpf: xdp, remove no longer required rcu_read_{un}lock() John Fastabend
2020-01-26 21:30 ` Jesper Dangaard Brouer
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=20200126222807.3f8e2268@carbon \
--to=brouer@redhat.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=toke@redhat.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.