does `radix_tree_insert` need `spin_lock` to protect it

60 views Asked by At

radix_tree_insert is protected by spin_lock in Linux kernel source code. But the dmesg shows warning information as below:

[  667.551326] dump_backtrace.cfi_jt+0x0/0x8
[  667.556266] show_stack+0x1c/0x2c
[  667.560415] dump_stack_lvl+0x94/0x100
[  667.565017] ___might_sleep+0x194/0x1e4
[  667.569688] __might_sleep+0x58/0x94
[  667.574112] slab_pre_alloc_hook+0x5c/0xf0
[  667.579066] kmem_cache_alloc+0x84/0x398
[  667.583830] radix_tree_node_alloc+0x74/0x138
[  667.589035] radix_tree_insert+0xf4/0x1fc

The warning information means radix_tree_insert might sleep, and it should not be in atomic context. I also notice radix_tree_insert is not protected by spin_lock in some code.

Does radix_tree_insert need to be protected by spin_lock? Do we need to care about the warning information?

1

There are 1 answers

0
Tsyvarev On

Like any other function, which modifies a radix tree, radix_tree_insert should be called under those synchronization, which (at least) prevents other modifications to operate concurrently. This is clearly written in the header include/linux/radix-tree.h which declares the radix tree:

  • any function modifying the tree or tags (inserting or deleting items, setting or clearing tags) must exclude other modifications, and exclude any functions reading the tree.

Depending on a usage scenario for a specific radix tree, such synchronization could be spinlock, mutex or something else.

Normally, a synchronization mechanism for a specific radix tree is described near its declaration. E.g. the declaration in the fs/btrfs/ctree.h is following:

    /*
     * radix tree that keeps track of delayed nodes of every inode,
     * protected by inode_lock
     */
    struct radix_tree_root delayed_nodes_tree;

A type of synchronization for modifications should take into account gfp mask parameter, which is passed to the constructor of the radix tree and used for nodes allocation. That is, if this mask parameter is GFP_KERNEL, then modification operations shouldn't be called under a spinlock.