linux-kernel - Re: [GIT PULL] Ceph fixes for 5.1-rc7

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]

Date:   Thu, 25 Apr 2019 14:23:59 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Ilya Dryomov <idryomov@...il.com>
Cc:     ceph-devel@...r.kernel.org,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] Ceph fixes for 5.1-rc7

On Thu, 2019-04-25 at 11:02 -0700, Linus Torvalds wrote:
> On Thu, Apr 25, 2019 at 10:48 AM Ilya Dryomov <idryomov@...il.com> wrote:
> > dentry name handling fixes from Jeff and a memory leak fix from Zheng.
> > Both are old issues, marked for stable.
> 
> Hmm. You probably should have talked to Al about the dentry name
> issue, because he'd most likely have pointed you towards our helper
> function for exactly this thing:
> 
>     struct name_snapshot stable;
> 
>     take_dentry_name_snapshot(&stable, dentry);
>     ... use stable.name ..
>     release_dentry_name_snapshot(&stable);
> 
> which doesn't need any extra memory allocation outside of some fairly
> limited stack allocation for the 'name_snapshot' itself, because it
> knows about the dentry name rules, and
> 
>  - for inline names, it copies it under the d_lock into the fixed
> DNAME_INLINE_LEN-sized buffer
> 
>  - for out-of-line names, it knows that the name allocation is stable
> and ref-counted, and just increments the refcount and uses the
> existing name pointer.
> 
> now, maybe you need to always do that name allocation anyway (looking
> at the diff it looks like you often do that for other cases), so maybe
> the name snapshot capability isn't all that useful for you and the
> above wouldn't have helped, but I suspect you might not even have
> realized that there was an option like this.
> 
> I've pulled this, but maybe Jeff wants to look at whether that
> snapshotting model could have helped.
> 
>                        Linus

Thanks for the info! I think it would have.

I took a quick look at the dcache code to see if we had something like
that before I did this, but I guess I didn't look closely enough. Those
routines do look nicer than my hand-rolled version.

I'll look at spinning up a patch to switch that over in the near future.

Thanks,
-- 
Jeff Layton <jlayton@...nel.org>