[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180816040145.gqzqicab4s6kcbye@ast-mbp.dhcp.thefacebook.com>
Date: Wed, 15 Aug 2018 21:01:47 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Colascione <dancol@...gle.com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Joel Fernandes <joelaf@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Tim Murray <timmurray@...gle.com>,
netdev <netdev@...r.kernel.org>,
Lorenzo Colitti <lorenzo@...gle.com>,
Chenbo Feng <fengc@...gle.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Alexei Starovoitov <ast@...com>
Subject: Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2)
command
On Tue, Aug 14, 2018 at 01:37:12PM -0700, Daniel Colascione wrote:
>
> > If we agree on that, should bpf_map_update handle it then?
> > Wouldn't it be much easier to understand and use from user pov?
> > No new commands to learn. map_update syscall replaced the map
> > and old map is no longer accessed by the program via this given map-in-map.
>
> Maybe with a new BPF_SYNCHRONIZE flag for BPF_MAP_UPDATE_ELEM and
> BPF_MAP_DELETE_ELEM. Otherwise, it seems wrong to make every user of
> these commands pay for synchronization that only a few will need.
I don't think extra flag is needed. Extra sync_rcu() for map-in-map
is useful for all users. I would consider it a bugfix,
since users that examine deleted map have this race today
and removing the race is always a good thing especially since the cost
is small.
Powered by blists - more mailing lists