Re: [PATCH bpf-next] libbpf: Add bpf_map__set_name()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux