linux-kernel - Re: [Ecryptfs-devel] [PATCH] ecryptfs: some inode attrs, and a question

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:	Sat, 17 Jan 2009 15:03:12 +0900
From:	hooanon05@...oo.co.jp
To:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Cc:	Tyler Hicks <tyhicks@...ux.vnet.ibm.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-kernel@...r.kernel.org, ecryptfs-devel@...ts.launchpad.net
Subject: Re: [Ecryptfs-devel] [PATCH] ecryptfs: some inode attrs, and a question 

Dave Kleikamp:
> I think you're hitting on something here.  I never understood  the need
> for the d_drop()s, but taking them out broke things.  They probably are
> just papering over bugs where the ecryptfs inode is not being properly
> updated after changes are made to the lower inode.

As long as cifs_hardlink() calls d_drop() for the target dentry (as the
old version of NFS did), ecryptfs may have to call d_drop() too. But I
believe the d_drop() for the source dentry is unnecessary, as long as
the inode attributes are maintained correctly.
Additionally, when the lower filesystem does NOT call d_drop(), ecryptfs
has no necessary to call it. I'd like to suggest ecryptfs_link() to
check it by d_unhashed().

J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/