[2.6.39-rc1] LTP hitting max (8) nested links...

[Daniel J Blueman]

When a test from the Linux Test Project [1] with 2.6.39-rc1 while
trying to reproduce another fileystem issue, I quickly hit the 8
nested link limit [2]:
BUG_ON(nd->depth >= MAX_NESTED_LINKS)

It seems a mutually exclusive condition to have such a technical limit
in-kernel and a test in LTP which triggers that, unless there is a bug
of course.

Though 8 seems reasonable in most cases, it looks like an artificial
and not technical limit which feels more broken - perhaps a WARN_ON or
higher limit before BUG() is called makes sense?

--- [1]

cd ltp/testcases/bin
TMPDIR=/tmp ./fs_racer.sh -t 30

--- [2]

kernel BUG at fs/namei.c:1380!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/virtual/misc/tun/uevent
CPU 0
Modules linked in: tun loop

Pid: 29776, comm: mkdir Tainted: G        W   2.6.39-rc1-350cd+ #9
Supermicro X8STi/X8STi
RIP: 0010:[<ffffffff8114cc34>]  [<ffffffff8114cc34>] link_path_walk+0x804/0x970
RSP: 0018:ffff8801e8441648  EFLAGS: 00010202
RAX: 0000000000000008 RBX: ffff8801e8441dd8 RCX: ffffffff8173b340
RDX: ffff8801ed09a1f0 RSI: ffff8801ed00dc80 RDI: ffff8801ed00dc80
RBP: ffff8801e84416f8 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000001 R12: ffff8802a1994002
R13: 000000000000002f R14: ffff8801e7798000 R15: ffff8802a1994002
FS:  00007fbdd94a47a0(0000) GS:ffff88031fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000403000 CR3: 00000001e842e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mkdir (pid: 29776, threadinfo ffff8801e8440000, task ffff8801e7798000)
Stack:
 ffffffff810e8090 ffff8801ed00dc80 ffff8801e84416e0 000000170000002f
 ffff8801e8441df8 ffff8801e7798000 ffff8801e8441de8 ffff8801e7798000
 ffff8801e8441698 ffff8801ed00dc80 0000000100002331 ffff8802a1994000
Call Trace:
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff810e8090>] ? find_get_pages+0x210/0x210
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff8114c97c>] link_path_walk+0x54c/0x970
 [<ffffffff8114f34d>] path_lookupat+0x2dd/0x860
 [<ffffffff8114f8fc>] do_path_lookup+0x2c/0xc0
 [<ffffffff8114d216>] ? getname_flags+0x126/0x250
 [<ffffffff81150ba4>] user_path_at+0x54/0xa0
 [<ffffffff81144fc7>] vfs_fstatat+0x47/0x80
 [<ffffffff81145036>] vfs_stat+0x16/0x20
 [<ffffffff8114520f>] sys_newstat+0x1f/0x50
 [<ffffffff810961fd>] ? trace_hardirqs_on_caller+0x14d/0x190
 [<ffffffff813325fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff81709d7b>] system_call_fastpath+0x16/0x1b
Code: ff 48 8b 85 60 ff ff ff e9 66 fd ff ff 48 8d 7d b0 48 89 de e8
1e e8 ff ff 48 89 df e8 c6 e9 ff ff b9 d8 ff ff ff e9 64 fa ff ff <0f>
0b eb fe 0f 0b eb fe 48 89 df e8 9c ea ff ff 85 c0 75 3b 48
RIP  [<ffffffff8114cc34>] link_path_walk+0x804/0x970
 RSP <ffff8801e8441648>
-- 
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/