From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command Date: Mon, 30 Jul 2018 18:14:50 -0700 Message-ID: <20180730181450.4e0e1df8@cakuba.netronome.com> References: <20180729205835.34850-1-dancol@google.com> <20180730172641.7d516231@cakuba.netronome.com> <20180730174532.20010e0d@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Daniel Borkmann , Joel Fernandes , linux-kernel , Tim Murray , netdev , Alexei Starovoitov , Lorenzo Colitti , Chenbo Feng , Mathieu Desnoyers , Alexei Starovoitov To: Daniel Colascione Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Mon, 30 Jul 2018 17:50:15 -0700, Daniel Colascione wrote: > > Tangentially it would be really useful for us to have a "the map has > > actually been freed" notification/barrier. We have complaints of users > > creating huge maps and then trying to free and recreate them quickly, > > and the creation part failing with -ENOMEM, because the free from a > > workqueue didn't run, yet :( It'd probably require a different API to > > solve than what's discussed here, but since we're talking about syncing > > things I thought I'd put it out there... > > Yeah. What you're talking about is what I meant upthread when I > briefly mentioned a "refcount draining approach" --- you'd block until > all references except your own to a map disappeared. I don't think so. The ref count goes to 0, work gets scheduled to call free, work runs, free gets called, device memory gets freed. Now the memory can be reused. As long as there are any refs we can't free memory, unless we want to make the semantics really ugly. But as I said, only superficially related to this patch. Perhaps solution will naturally fall out of an API to query the device capabilities and resources, if we ever get there.