On Wed, Jul 13, 2022 at 4:02 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > On Wed, Jul 13, 2022 at 3:32 PM Joe Burton <jevburton@xxxxxxxxxx> wrote: > > > > > Asked you internally, but not sure I follow. Can you share more on why > > > the following won't fix it for us: > > > > > > https://lore.kernel.org/bpf/OSZP286MB1725CEA1C95C5CB8E7CCC53FB8869@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > ? > > > > > > The idea seems to be to get the supplied map name (from the obj) > > > instead of using pin name? So why is it not enough? > > > > You're correct, this approach also resolves the issue. No need for this > > new API. > > SG! New helper might still be useful, but I'm not sure how safe that > is, given how much we use the name internally in libbpf > (name/pin_path). So it might be safer to use Anquan's approach for > now. > > Andrii, any concerns with [1] ? Should we pull that in? I already applied [1]. I'm uncomfortable with bpf_map__set_name() in general, because map name is tied into BTF and other things, so it needs much more careful thinking how to support sudden map renames. But given the problem was with bpf_map__reuse_fd(), I think [1] solves it already. > > [1] https://lore.kernel.org/bpf/OSZP286MB1725CEA1C95C5CB8E7CCC53FB8869@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
