linux 核心（特別是 2.6 以後的版本）是否有任何遞歸函式？

鑑於核心堆棧的固定大小有限，我的猜測是，雖然理論上我們可能有一個遞歸函式，如果它的遞歸不會太深，實用主義會建議一起取消遞歸函式，以更安全。畢竟，過多的遞歸會導致擦除 thread_info_t 結構並導致核心恐慌

是的！

也許一些遞歸呼叫要麼記錄在案，要麼是函式名的一部分？然後，一個 find/grep 應該顯示它們。這是執行此操作的命令：

find /usr/src/linux/ -name "*.c" -exec grep recursive {} ";" -ls 

管道通過| wc -l 給我 270，也就是說，因為 -ls 為每個文件多列印一行，至少 135 個文件+函式。

讓我們看一下第一場比賽：

/usr/src/linux/fs/jfs/jfs_dmap.c

比賽是評論：

• 如果 dmap 控制頁面的調整本身導致其
• root 要更改，此更改將冒泡到下一個 dmap
• 通過對該常式的遞歸呼叫控制級別，指定
• 新的根值和下一個 dmap 控制頁面級別
• 進行調整。

在方法前面

static int
dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level)

事實上，第 2486 行和鄰居是：

if (dcp->stree[ROOT] != oldroot) {
   /* are we below the top level of the map.  if so,
    * bubble the root up to the next higher level.
    */
   if (level < bmp->db_maxlevel) {
       /* bubble up the new root of this dmap control page to
        * the next level.
        */
       if ((rc =
            dbAdjCtl(bmp, blkno, dcp->stree[ROOT], alloc,
                 level + 1))) {
           /* something went wrong in bubbling up the new
            * root value, so backout the changes to the
            * current dmap control page.
            */

由於問題是，是否存在任何遞歸函式，我們不必訪問接下來的 135 個或更多匹配項或搜尋未明確提及的遞歸。答案是

是的！

引用自：https://unix.stackexchange.com/questions/37302