Re: [PATCH bpf-next 07/10] bpf: Switch to bpf mem allocator for LPM trie

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

 



On Thu, Nov 21, 2024 at 12:39:08PM +0100, Toke Høiland-Jørgensen wrote:
> Hou Tao <houtao@xxxxxxxxxxxxxxx> writes:
> 
> > Fix these warnings by replacing kmalloc()/kfree()/kfree_rcu() with
> > equivalent bpf memory allocator APIs. Since intermediate node and leaf
> > node have fixed sizes, fixed-size allocation APIs are used.
> >
> > Two aspects of this change require explanation:
> >
> > 1. A new flag LPM_TREE_NODE_FLAG_ALLOC_LEAF is added to track the
> >    original allocator. This is necessary because during deletion, a leaf
> >    node may be used as an intermediate node. These nodes must be freed
> >    through the leaf allocator.
> > 2. The intermediate node allocator and leaf node allocator may be merged
> >    because value_size for LPM trie is usually small. The merging reduces
> >    the memory overhead of bpf memory allocator.
> 
> This seems like an awfully complicated way to fix this. Couldn't we just
> move the node allocations in trie_update_elem() out so they happen
> before the trie lock is taken instead?

The problematic lock nesting is not between the trie lock and the
allocator lock but between each of them and any other lock in the kernel.
BPF programs can be called from any context through tracepoints.
In this specific case the issue was a tracepoint executed under the
workqueue lock.


Thomas




[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