Re: [PATCH bpf-next v3 2/3] bpf: Support kptrs in local storage maps

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

 



On 3/4/23 7:34 AM, Kumar Kartikeya Dwivedi wrote:
@@ -113,10 +114,25 @@ static void bpf_selem_free_rcu(struct rcu_head *rcu)
       struct bpf_local_storage_elem *selem;

       selem = container_of(rcu, struct bpf_local_storage_elem, rcu);
+     /* The can_use_smap bool is set whenever we need to free additional
+      * fields in selem data before freeing selem. bpf_local_storage_map_free
+      * only executes rcu_barrier to wait for RCU callbacks when it has
+      * special fields, hence we can only conditionally dereference smap, as
+      * by this time the map might have already been freed without waiting
+      * for our call_rcu callback if it did not have any special fields.
+      */
+     if (selem->can_use_smap)
+             bpf_obj_free_fields(SDATA(selem)->smap->map.record, SDATA(selem)->data);
+     kfree(selem);
+}
+
+static void bpf_selem_free_tasks_trace_rcu(struct rcu_head *rcu)
+{
+     /* Free directly if Tasks Trace RCU GP also implies RCU GP */
       if (rcu_trace_implies_rcu_gp())
-             kfree(selem);
+             bpf_selem_free_rcu(rcu);
       else
-             kfree_rcu(selem, rcu);
+             call_rcu(rcu, bpf_selem_free_rcu);
   }

   /* local_storage->lock must be held and selem->local_storage == local_storage.
@@ -170,9 +186,9 @@ static bool bpf_selem_unlink_storage_nolock(struct bpf_local_storage *local_stor
               RCU_INIT_POINTER(local_storage->cache[smap->cache_idx], NULL);

       if (use_trace_rcu)
-             call_rcu_tasks_trace(&selem->rcu, bpf_selem_free_rcu);
+             call_rcu_tasks_trace(&selem->rcu, bpf_selem_free_tasks_trace_rcu);
       else
-             kfree_rcu(selem, rcu);
+             call_rcu(&selem->rcu, bpf_selem_free_rcu);
After another thought, bpf_obj_free_fields() does not need to go through the rcu
gp, right?

bpf_obj_free_fields() can be done just before the call_rcu_tasks_trace() and the
call_rcu() here. In hashtab, bpf_obj_free_fields() is also done just before
bpf_mem_cache_free().
Perhaps not. But the original code for hashtab prior to conversion to
use bpf_mem_cache actually freed timers and kptrs after waiting for a
complete RCU grace period for the kmalloc case. My main idea was to
try to delay it until the last point, where memory is returned for
reuse. Now that does not include a RCU grace period for hashtab
anymore because memory can be reused as soon as it is returned to
bpf_mem_cache. Same for array maps where update does the freeing.

bpf_obj_free_fields can possibly do a lot of work, try to acquire the
bpf_spin_lock in map value, etc. Even moreso now that we have lists
and rbtree that could be in map values, where they have to drain all
elements (which might have fields of their own). Not doing that in the
context of the program calling update or delete is usually better if
we have a choice, since it might introduce unexpected delays. Here we
are doing an RCU callback in all cases, so I think it's better to
delay freeing the fields and do it in RCU callback, since we are doing
call_rcu anyway.

The delete_elem for local storage is not the common use case. The usage is usually to have the storage stay with its owner lifetime until the bpf storage is destroyed by bpf_{sk,task,inode,cgrp}_storage_free. The userspace does not need to track the lifetime of its owner which could be fragile.

More importantly, I am moving local storage to bpf_mem_cache_alloc/free because of potential deadlock during the kmalloc time: https://lore.kernel.org/bpf/dea8c3c5-0739-58c1-9a88-b989878a9b8f@xxxxxxxxx/ Thus, bpf_obj_free_fields() needs to be done before freeing the selem. I have already made this change in my set and will post shortly.

Thanks for the prompt reply!



[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