`radix_tree_insert`需要`spin_lock`来保护它吗

Question

radix_tree_insert在Linux内核源代码中受到spin_lock的保护。但是，dmesg显示了如下警告信息：

[  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

警告信息意味着radix_tree_insert可能会休眠，它不应该在原子上下文中。我还注意到，在某些代码中，radix_tree_insert不受spin_lock的保护。

radix_tree_insert需要受到spin_lock的保护吗？我们需要关心警告信息吗？

Answer 1

与修改作为基树的任何其他函数一样，应该在这些同步下调用radix_tree_insert，这(至少)阻止了其他修改并发操作。这清楚地写在报头包括/linux/基-tree.h中，它声明了基树：

• 任何修改树或标记的函数(插入或删除项、设置或清除标记)都必须排除其他修改，并排除读取树的任何函数。

根据特定于的基树的使用场景，这种同步可能是自旋锁、互斥或其他什么。

通常，特定基树的同步机制在其声明附近被描述。例如，fs/btrfs/ctree.h中的声明如下：

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

用于修改的同步类型应该考虑gfp掩码参数，gfp掩码参数传递给基树的构造函数并用于节点分配。也就是说，如果这个掩码参数是GFP_KERNEL，那么修改操作不应该在自旋锁下调用。