3

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.

3

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.

| improve this answer | |
4

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.

| improve this answer | |
  • Yeah, it's possible. Do you have any clue how /proc "adds another level of indirection"? Is there any tool to show the current stacking depth of a file system? – Duan Yao Jun 19 '17 at 7:51
  • > ". I don't see any obvious reason why it can't stack deeper" - kernel stacks are very small fixed-size allocations, unlike user-space. lwn.net/Articles/692953 – sourcejedi Jun 19 '17 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.