From: Sedat Dilek <sedat.dilek@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, hch@infradead.org,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
apw@canonical.com, nbd@openwrt.org, neilb@suse.de,
jordipujolp@gmail.com, ezk@fsl.cs.sunysb.edu,
ricwheeler@gmail.com, dhowells@redhat.com, hpj@urpla.net,
sedat.dilek@googlemail.com, penberg@kernel.org,
goran.cetusic@gmail.com, romain@orebokech.com
Subject: Re: [PATCH 08/13] fs: limit filesystem stacking depth
Date: Thu, 16 Aug 2012 15:24:08 +0200 [thread overview]
Message-ID: <CA+icZUVz1DNBipOOT_j+ewKSuuFR0775RKyRWq4CcDqwafqC8Q@mail.gmail.com> (raw)
In-Reply-To: <87sjbnce4k.fsf@tucsk.pomaz.szeredi.hu>
[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]
On Thu, Aug 16, 2012 at 12:42 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> Sedat Dilek <sedat.dilek@gmail.com> writes:
>
>> On Wed, Aug 15, 2012 at 5:48 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> From: Miklos Szeredi <mszeredi@suse.cz>
>>>
>>> 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 "testcase-ovl-v3.sh").
>> 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.
>
Can you describe such an analysis method (in case you need help for testing it)?
>
>> [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
> increased.
>
No, it was Jordi's test-case script :-).
Unfortunately, my modified version had a brownbag included and will
not run (forgot a comment sign).
v4 attached is included in the atched tarball (see scripts/).
I have added my test-results against a slightly modified Linux-Next
(next-20120816) kernel (see patches/).
All relevant material is in the TAR-XZ archive (see also attached ls-lR.txt).
AFAICS Jordi is creating 3x Upper/Lower/Root dirs/mounts/etc., that's
why a "fs-stack-max-depth=3" is minimum requirement.
( Just FYI: The "LOG-24G" log-file below
TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ has detailed
informations. )
Hope this helps you.
- Sedat -
> Thanks,
> Miklos
[-- Attachment #2: ls-lR.txt --]
[-- Type: text/plain, Size: 2201 bytes --]
.:
total 20
drwxr-xr-x 9 wearefam wearefam 4096 Aug 16 15:06 TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:06 kernel-config
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:10 logs
-rw-rw-r-- 1 wearefam wearefam 0 Aug 16 15:11 ls-lR.txt
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:11 patches
drwxrwxr-x 2 wearefam wearefam 4096 Aug 16 15:05 scripts
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq:
total 4736
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 COW-r0b
-rw-r--r-- 1 wearefam wearefam 134217728 Aug 16 14:54 COWFILE-ZdO
-rw-r--r-- 1 wearefam wearefam 127944 Aug 16 14:54 LOG-24G
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 ROOT-RO-DmL
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 ROOT-RO-dxr
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 ROOT-sxo
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 UPPER-OCW
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 UPPER-ULU
drwxr-xr-x 2 wearefam wearefam 4096 Aug 16 14:54 UPPER-nJm
-rw-r--r-- 1 wearefam wearefam 4096 Aug 16 14:54 WORK-6S5.squashfs
-rw-r--r-- 1 wearefam wearefam 4096 Aug 16 14:54 WORK-gSq.squashfs
-rw-r--r-- 1 wearefam wearefam 4096 Aug 16 14:54 WORK-wBd.squashfs
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/COW-r0b:
total 0
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ROOT-RO-DmL:
total 0
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ROOT-RO-dxr:
total 0
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/ROOT-sxo:
total 0
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/UPPER-OCW:
total 0
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/UPPER-ULU:
total 0
./TEST-3.6.0-rc1-next20120816-1-iniza-generic-DLq/UPPER-nJm:
total 0
./kernel-config:
total 144
-rw-r--r-- 1 wearefam wearefam 145381 Aug 16 13:42 config-3.6.0-rc1-next20120816-1-iniza-generic
./logs:
total 56
-rw-rw-r-- 1 wearefam wearefam 54421 Aug 16 15:09 dmesg_3.6.0-rc1-next20120816-1-iniza-generic_HIDDEN.txt
./patches:
total 136
-rw-rw-r-- 1 wearefam wearefam 137929 Aug 16 12:47 3.6.0-rc1-next20120816-1-iniza-generic.patch
./scripts:
total 8
-rwxr-xr-x 1 wearefam wearefam 4925 Aug 16 14:58 testcase-ovl-v4.sh
[-- Attachment #3: overlayfs-v14_tested-by-dileks.tar.xz --]
[-- Type: application/octet-stream, Size: 107384 bytes --]
[-- Attachment #4: overlayfs-v14_tested-by-dileks.tar.xz.sha256sum --]
[-- Type: application/octet-stream, Size: 104 bytes --]
89d4c6e58a550fe6f414e2066bb9a982dfc5375586f6393ab0d3baac00b88eed overlayfs-v14_tested-by-dileks.tar.xz
next prev parent reply other threads:[~2012-08-16 13:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 15:48 [PATCH 00/13] overlay filesystem: request for inclusion (v14) Miklos Szeredi
2012-08-15 15:48 ` [PATCH 01/13] vfs: add i_op->open() Miklos Szeredi
2012-08-15 17:21 ` J. Bruce Fields
2012-08-15 20:28 ` NeilBrown
2012-08-16 10:10 ` Miklos Szeredi
2012-08-15 15:48 ` [PATCH 02/13] vfs: export do_splice_direct() to modules Miklos Szeredi
2012-08-15 15:48 ` [PATCH 03/13] vfs: introduce clone_private_mount() Miklos Szeredi
2012-08-15 15:48 ` [PATCH 04/13] overlay filesystem Miklos Szeredi
2012-08-16 6:24 ` Eric W. Biederman
2012-08-16 10:25 ` Miklos Szeredi
2012-08-15 15:48 ` [PATCH 05/13] overlayfs: add statfs support Miklos Szeredi
2012-08-17 18:20 ` Ben Hutchings
2012-08-29 22:48 ` Miklos Szeredi
2012-08-30 5:54 ` Ben Hutchings
2012-08-31 12:47 ` J. R. Okajima
2012-08-15 15:48 ` [PATCH 06/13] overlayfs: implement show_options Miklos Szeredi
2012-08-15 15:48 ` [PATCH 07/13] overlay: overlay filesystem documentation Miklos Szeredi
2012-08-15 19:53 ` J. Bruce Fields
2012-08-16 10:09 ` Miklos Szeredi
2012-09-10 1:47 ` Jan Engelhardt
2012-09-10 3:18 ` NeilBrown
2012-08-15 15:48 ` [PATCH 08/13] fs: limit filesystem stacking depth Miklos Szeredi
2012-08-16 8:02 ` Sedat Dilek
2012-08-16 8:30 ` Sedat Dilek
2012-08-16 10:42 ` Miklos Szeredi
2012-08-16 13:24 ` Sedat Dilek [this message]
2012-09-03 15:05 ` Miklos Szeredi
2012-08-15 15:48 ` [PATCH 09/13] overlayfs: fix possible leak in ovl_new_inode Miklos Szeredi
2012-08-15 15:48 ` [PATCH 10/13] overlayfs: create new inode in ovl_link Miklos Szeredi
2012-08-15 15:48 ` [PATCH 11/13] vfs: export __inode_permission() to modules Miklos Szeredi
2012-08-15 17:17 ` Sedat Dilek
2012-08-15 15:48 ` [PATCH 12/13] ovl: switch to __inode_permission() Miklos Szeredi
2012-08-15 16:59 ` Casey Schaufler
2012-08-15 17:07 ` Andy Whitcroft
2012-08-15 17:34 ` Casey Schaufler
2012-08-15 15:48 ` [PATCH 13/13] overlayfs: copy up i_uid/i_gid from the underlying inode Miklos Szeredi
2012-08-15 17:14 ` [PATCH 00/13] overlay filesystem: request for inclusion (v14) Sedat Dilek
2012-09-20 18:55 [PATCH 00/13] overlay filesystem: request for inclusion (v15) Miklos Szeredi
2012-09-20 18:55 ` [PATCH 08/13] fs: limit filesystem stacking depth Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+icZUVz1DNBipOOT_j+ewKSuuFR0775RKyRWq4CcDqwafqC8Q@mail.gmail.com \
--to=sedat.dilek@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=dhowells@redhat.com \
--cc=ezk@fsl.cs.sunysb.edu \
--cc=goran.cetusic@gmail.com \
--cc=hch@infradead.org \
--cc=hpj@urpla.net \
--cc=jordipujolp@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=nbd@openwrt.org \
--cc=neilb@suse.de \
--cc=penberg@kernel.org \
--cc=ricwheeler@gmail.com \
--cc=romain@orebokech.com \
--cc=sedat.dilek@googlemail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).