All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <kafai@fb.com>
To: Hou Tao <houtao1@huawei.com>
Cc: <netdev@vger.kernel.org>, <bpf@vger.kernel.org>
Subject: Re: Question about the release of BPF_MAP_TYPE_STRUCT_OPS fd
Date: Tue, 28 Sep 2021 11:33:19 -0700	[thread overview]
Message-ID: <20210928183319.vd4q5ydqg6twasqj@kafai-mbp> (raw)
In-Reply-To: <a6ba3289-accd-051a-b27c-d90df0eb7cd2@huawei.com>

On Tue, Sep 28, 2021 at 10:13:45PM +0800, Hou Tao wrote:
> Hi Martin,
> 
> During the testing of bpf_tcp_ca, I found that if the test program
> aborts before calling bpf_link__detach_struct_ops(), the registered
> bpf_dctcp will not be unregistered, and running bpf_tcp_ca test again
> will fail with -EEXIST error as shown below:
> 
> test_dctcp:PASS:bpf_dctcp__open_and_load 0 nsec
> test_dctcp:FAIL:bpf_map__attach_struct_ops unexpected error: -17
> 
> The root cause is that the release of BPF_MAP_TYPE_STRUCT_OPS fd
> neither put struct_ops programs in maps nor unregister the struct_ops
> from kernel. Was the implementation intentional, or was it an oversight ?
> If it is an oversight, I will post a patch to fix it.
The original use case for the struct_ops is to register and unregister
by command like "bpftool struct_ops (un)register" and then
the kernel sub-system (tcp here) owns it, instead of finding where the maps
may be pinned (could be in multiple locations).  More like the insmod/rmmod.

I think you meant to unregister it in ".map_release_uref"? but it will break
the existing contract above.  I believe a better way to do the auto-unreg
is to create a real bpf_link for struct_ops.  bpf_link has been added to
the xdp and cgroup attachments since then.  I did not give too much
thoughts on this yet.

What bpf-tcp-cc are you implementing
or it is for running the test_progs purpose only ?

      reply	other threads:[~2021-09-28 18:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28 14:13 Question about the release of BPF_MAP_TYPE_STRUCT_OPS fd Hou Tao
2021-09-28 18:33 ` Martin KaFai Lau [this message]

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=20210928183319.vd4q5ydqg6twasqj@kafai-mbp \
    --to=kafai@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=houtao1@huawei.com \
    --cc=netdev@vger.kernel.org \
    /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.