linux-kernel - RE: [GIT PULL] iomap: new code for 5.13-rc1

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: <AM6PR08MB437611323F93C76F0D2703C6F75E9@AM6PR08MB4376.eurprd08.prod.outlook.com>
Date:   Fri, 30 Apr 2021 06:13:40 +0000
From:   Justin He <Justin.He@....com>
To:     Al Viro <viro@...iv.linux.org.uk>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Christoph Hellwig <hch@....de>,
        "Darrick J. Wong" <djwong@...nel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Dave Chinner <david@...morbit.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Sandeen <sandeen@...deen.net>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: RE: [GIT PULL] iomap: new code for 5.13-rc1

Hi Al Viro

> -----Original Message-----
> From: Al Viro <viro@....linux.org.uk> On Behalf Of Al Viro
> Sent: Friday, April 30, 2021 11:21 AM
> To: Justin He <Justin.He@....com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>; Rasmus Villemoes
> <linux@...musvillemoes.dk>; Christoph Hellwig <hch@....de>; Darrick J. Wong
> <djwong@...nel.org>; linux-fsdevel <linux-fsdevel@...r.kernel.org>; linux-
> xfs <linux-xfs@...r.kernel.org>; Dave Chinner <david@...morbit.com>; Linux
> Kernel Mailing List <linux-kernel@...r.kernel.org>; Eric Sandeen
> <sandeen@...deen.net>; Andy Shevchenko <andy.shevchenko@...il.com>
> Subject: Re: [GIT PULL] iomap: new code for 5.13-rc1
>
> On Fri, Apr 30, 2021 at 03:17:02AM +0000, Justin He wrote:
>
> > Is it a good idea to introduce a new d_path_nolock() for
> file_dentry_name()?
> > In d_path_nolock(), if it detects that there is conflicts with mount_lock
> > or rename_lock, then returned NULL as a name of that vfsmount?
>
> Just what does vfsmount have to do with rename_lock?  And what's the point
> of the entire mess, anyway?

Sorry, do you suggest not considering rename_lock/mount_lock at all for file_dentry_name()?

--
Cheers,
Justin (Jia He)


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.