Re: [PATCH bpf-next,v4 2/4] xfrm: interface: Add unstable helpers for setting/getting XFRM metadata from TC-BPF

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

 



Hi Martin,

On Fri, Dec 2, 2022 at 9:08 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
>
> On 12/2/22 1:59 AM, Eyal Birger wrote:
> > +__used noinline
> > +int bpf_skb_set_xfrm_info(struct __sk_buff *skb_ctx,
> > +                       const struct bpf_xfrm_info *from)
> > +{
> > +     struct sk_buff *skb = (struct sk_buff *)skb_ctx;
> > +     struct metadata_dst *md_dst;
> > +     struct xfrm_md_info *info;
> > +
> > +     if (unlikely(skb_metadata_dst(skb)))
> > +             return -EINVAL;
> > +
> > +     md_dst = this_cpu_ptr(xfrm_md_dst);
> > +
> > +     info = &md_dst->u.xfrm_info;
> > +
> > +     info->if_id = from->if_id;
> > +     info->link = from->link;
> > +     skb_dst_force(skb);
> > +     info->dst_orig = skb_dst(skb);
> > +
> > +     dst_hold((struct dst_entry *)md_dst);
> > +     skb_dst_set(skb, (struct dst_entry *)md_dst);
>
>
> I may be missed something obvious and this just came to my mind,
>
> What stops cleanup_xfrm_interface_bpf() being run while skb is still holding the
> md_dst?
>
Oh I think you're right. I missed this.

In order to keep this implementation I suppose it means that the module would
not be allowed to be removed upon use of this kfunc. but this could be seen as
annoying from the configuration user experience.

Alternatively the metadata dsts can be separately allocated from the kfunc,
which is probably the simplest approach to maintain, so I'll work on that
approach.

Thanks for noticing this!
Eyal.



[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