linux-kernel - Re: [PATCH] vfs: make open_with_fake_path() not contribute to nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Jul 2018 10:49:59 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     David Howells <dhowells@...hat.com>
Cc:     Miklos Szeredi <mszeredi@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] vfs: make open_with_fake_path() not contribute to nr_files

On Thu, Jul 19, 2018 at 10:09 AM, David Howells <dhowells@...hat.com> wrote:
> Miklos Szeredi <mszeredi@...hat.com> wrote:
>
>> Stacking file operations in overlay will store an extra open file for each
>> overlay file opened.
>>
>> The overhead is just that of "struct file" which is about 256bytes, because
>> overlay already pins an extra dentry and inode when the file is open, which
>> add up to a much larger overhead.
>>
>> For fear of breaking working setups, don't start accounting the extra file.
>
> Sounds useful for cachefiles too, though Christoph Hellwig objected strongly
> last time I tried this, so you might want to check with him directly.

What the cachefiles use case would be?

Overlayfs wants the "shadow" file open only as long as the real file
is open.  Is the cachefiles case the same?

For overlays the real cost of pinned memory by open files  is already
sunk in the layered dentry references.  Which means overlayfs is
already pinning substantially more memory for an open file than other
fs (by about a factor of 2-3, due to pinned lower and/or upper
dentries and inodes).   If this was a problem in real life, then we'd
be already be in trouble.  The stacked open file patch only adds the
overhead of the actual struct file, which is small compared to the
multiple pinned dentry and inode structs.

Christoph already commented on a previous version of the patch and I
pointed out the above.

Thanks,
Miklos