Why can't /proc be a layer of a overlay file system (overlayfs) on linux?

Question

Run the following commands on linux (4.4.59 and 4.9.8 are tested) and it will fail:

mkdir -p /tmp/proc
mount -t overlay overlay -o lowerdir=/proc:/tmp/proc /tmp/proc

and there is a error message in dmesg:

overlayfs: maximum fs stacking depth exceeded

Why can't /proc be a layer of a overlay file system?
If I replace /proc with /dev or /sys, it mounts without issue, so it seems there is something special with /proc.

P.S. The use case is creating a safer chroot environment, I want to make /dev, /sys and /proc read-only in chroot. There are 2 known workarounds:

1. read-only bind mount. The limitation is two commnads instead one required.
2. read-only special mount: mount -t proc -o ro none /tmp/proc. The limitation is sub-mount not mapped automatically.

Anyway, I'm still curious about why /dev and /sys play well with overlay but /proc doesn't.

The question is migrated from stackoverflow.

Answer 1

https://github.com/torvalds/linux/commit/e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9

    /*
     * procfs isn't actually a stacking filesystem; however, there is
     * too much magic going on inside it to permit stacking things on
     * top of it
     */
s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;

This might not be a very informative answer, but the kernel developers specifically don't support it.

Answer 2

Grepping for "depth" in /usr/src/linux/fs/overlayfs finds that it's just a simple checking of the current stacking depth against FILESYSTEM_MAX_STACK_DEPTH. Search for that in the include files finds that FILESYSTEM_MAX_STACK_DEPTH is defined to be 2 in /usr/src/linux/include/linux/fs.h. The comment says

Maximum number of layers of fs stack. Needs to be limited to prevent kernel stack overflow

So apparently because the proc-filesystem adds another level of indirection compared to dev or sys, you exceed the stacking depth. I don't see any obvious reason why it can't stack deeper, so try increasing FILESYSTEM_MAX_STACK_DEPTH, recompile your kernel, and see if it works. This may cause the kernel to use more stack, so therefore more memory in general, and it may make it slower - I don't know details about the implementation.

Edit in response to comment

My guess is that the proc filesystem has to keep track of files per module, so it can remove them when the module is removed. Basically it's an overlay file system for all modules. But I'd have to read the source in detail to verify that (and you can read the source, too. :-).

The stacking depth is in the stack_depth field of the superblock structure, so to show it, you need some way to access kernel data structures. I suppose some kernel debugging tool could do that (or you can always write a kernel extension/module that displays it somewhere), but I don't know any concrete way.