[lkml]   [2012]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 08/13] fs: limit filesystem stacking depth
Sedat Dilek <> writes:

> On Wed, Aug 15, 2012 at 5:48 PM, Miklos Szeredi <> wrote:
>> From: Miklos Szeredi <>
>> Add a simple read-only counter to super_block that indicates deep this
>> is in the stack of filesystems. Previously ecryptfs was the only
>> stackable filesystem and it explicitly disallowed multiple layers of
>> itself.
>> Overlayfs, however, can be stacked recursively and also may be stacked
>> on top of ecryptfs or vice versa.
>> To limit the kernel stack usage we must limit the depth of the
>> filesystem stack. Initially the limit is set to 2.
> Hi,
> I have tested OverlayFS for a long time with "fs-stack-depth=3".
> The original OverlayFS test-case script from Jordi was slightly
> modified (see "").
> I have sent my test-results to Andy and Jordi (tested with the
> patchset from Andy against Linux-v3.4 [1] with Ext4-FS).
> The attached test-case script *requires* "fs-stack-depth=3" to run
> properly (patch attached).
> So, I have 2 questions:
> [1] FS-stack-limitation
> Is a "fs-stack-depth>=2" (like "3") critical?
> Is your setting to "2" just a defensive (and initial) one?
> Can you explain your choice a bit more as ecryptFS is involved in this
> limitation, too.

If directly stacking filesystems like this on top of each other
(ecryptfs is currently the only filesystem that does this in mainline)
then the call chain can get too long and the kernel stack overflow.

Yes, setting it to 2 is defensive, it would need more stack depth
analysis to see what an acceptable number would be.

> [2] Test-Case/Use-Case scripts
> It would be *very very very* helpful if you could provide or even ship
> in the Linux-kernel a test-case/use-case script, Thanks!

Sure, I could add Andy's test script under the tools/ directory. But I
don't understand why exactly it needs the stacking depth to be


 \ /
  Last update: 2012-08-16 13:21    [W:0.165 / U:5.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site