On 8/20/20 4:33 AM, Lorenz Bauer wrote:
On Wed, 19 Aug 2020 at 23:41, John Fastabend wrote:
John Fastabend wrote:
Lorenz Bauer wrote:
Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
context. The synchronization required for this is a bit fiddly: we
need to prevent the
On Wed, 19 Aug 2020 at 23:41, John Fastabend wrote:
>
> John Fastabend wrote:
> > Lorenz Bauer wrote:
> > > Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
> > > context. The synchronization required for this is a bit fiddly: we
> > > need to prevent the socket from changing i
John Fastabend wrote:
> Lorenz Bauer wrote:
> > Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
> > context. The synchronization required for this is a bit fiddly: we
> > need to prevent the socket from changing it's state while we add it
> > to the sockmap, since we rely on ge
Lorenz Bauer wrote:
> Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
> context. The synchronization required for this is a bit fiddly: we
> need to prevent the socket from changing it's state while we add it
> to the sockmap, since we rely on getting a callback via
> sk_prot->
On 8/19/20 2:24 AM, Lorenz Bauer wrote:
Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
context. The synchronization required for this is a bit fiddly: we
need to prevent the socket from changing it's state while we add it
to the sockmap, since we rely on getting a callbac
Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
context. The synchronization required for this is a bit fiddly: we
need to prevent the socket from changing it's state while we add it
to the sockmap, since we rely on getting a callback via
sk_prot->unhash. However, we can't just
6 matches
Mail list logo