linux-kernel - Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 19 Jul 2018 11:13:24 +0200
From:   Jan Kara <jack@...e.cz>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Dave Chinner <david@...morbit.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Waiman Long <longman@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jonathan Corbet <corbet@....net>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Jan Kara <jack@...e.cz>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>,
        Ingo Molnar <mingo@...nel.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Wangkai (Kevin,C)" <wangkai86@...wei.com>
Subject: Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries

On Thu 19-07-18 10:45:38, Michal Hocko wrote:
> On Thu 19-07-18 10:33:29, Dave Chinner wrote:
> > > > and, apart from the external name thing (grr), that should address
> > > > these fragmentation issues, no?  I assume it's easy to ask slab how
> > > > many pages are presently in use for a particular cache.
> > > 
> > > I remember Dave Chinner had an idea how to age dcache pages to push
> > > dentries with similar live time to the same page. Not sure what happened
> > > to that.
> > 
> > Same thing that happened to all the "select the dentries on this
> > page for reclaim". i.e. it's referenced dentries that we can't
> > reclaim or move that are the issue, not the reclaimable dentries on
> > the page.
> > 
> > Bsaically, without a hint at allocation time as to the expected life
> > time of the dentry, we can't be smart about how we select partial
> > pages to allocate from. And because we don't know at allocation time
> > if the dentry is going to remain a negative dentry or not, we can't
> > provide a hint about expected lifetime of teh object being
> > allocated.
> 
> Can we allocate a new dentry at the time when we know the life time or
> the dentry pointer is so spread by that time that we cannot?

It's difficult. We allocate dentry, put it in our structures, use it for
synchronization e.g. of parallel lookups of the same name (so for that it is
important that it is visible to everybody) and only after that we ask
filesystem what does it have (if anything) under that name... So delaying
allocation would mean overhauling the locking logic in the whole dcache.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR