linux-kernel - Re: [PATCH 1/8] vfs: new d

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOssrKeCxcOxx4H1z6m8p7AD+cgt9nd30aCUns3U4vOx41skYg@mail.gmail.com>
Date:	Wed, 22 Jun 2016 22:33:12 +0200
From:	Miklos Szeredi <mszeredi@...hat.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 1/8] vfs: new d_allocate method

On Wed, Jun 22, 2016 at 7:02 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Wed, Jun 22, 2016 at 04:35:03PM +0200, Miklos Szeredi wrote:
>> Allow filesystem to initialize dentry (->d_fsdata to be explicit) at
>> allocation time.
>
> Something similar had been discussed a while ago (I don't remember whether
> you'd been on Cc, though).  E.g. ceph and lustre would benefit from having
> such method (proposed name was ->d_init(), seeing that it's not always
> just an allocation).  The subtle part is barriers and I would really like
> to see a proof that you don't need any.

Thanks for the review.  Yeah, I missed the rcu concequences.  And I
also didn't benchmark anything, it's obviously going to hurt somewhat
for fs that need to alloc an fsdata due to this.  I'm waiting to hear
better ideas.

One, rather ugly, is to make the max internal name length fs depenent,
and allow fs to use that space if it wants to trading it for a longer
d_iname.

Thaks,
Miklos