linux-kernel - Re: [PATCH 04/28] OCFS2 is screwy

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: <20060802021411.GG29686@ca-server1.us.oracle.com>
Date:	Tue, 1 Aug 2006 19:14:11 -0700
From:	Mark Fasheh <mark.fasheh@...cle.com>
To:	Dave Hansen <haveblue@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, viro@....linux.org.uk,
	herbert@...hfloor.at, hch@...radead.org
Subject: Re: [PATCH 04/28] OCFS2 is screwy

On Tue, Aug 01, 2006 at 04:52:43PM -0700, Dave Hansen wrote:
> OCFS2 plays some games with i_nlink.  It modifies it a bunch in
> its unlink function, but rolls back the changes if an error
> occurs.  So, we can't just assume that iput_final() will happen
> whenever i_nlink hits 0 in ocfs's unlink().
Huh? Did you read the code? Or is it just easier to call things "screwy" and
start hacking away?

i_nlink only gets rolled back in the case that the file system wasn't able to
actually complete the unlink / orphan operation. The idea is to keep it in
sync with what's actually on disk. So when we call iput() in the unlink
path, disk and struct inode should be accurate.

> Create a helper function to do the hard work of i_nlink hitting
> zero, and use it in ocfs2.
Anyway, it's only done that way because at the time it seemed the cleanest
approach - there's no technical reason why we must roll it back. So a helper
function doesn't seem necessary - you'd just have to look through the small
amount of code and re-order things a bit.

Unfortunately you didn't actually put the contents of
__inode_set_awaiting_final_iput() in this patch, so I'll have to dig through
the others to see what exactly you're up to. In the meantime I'd say this
patch is either unecessary or just plain wrong.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@...cle.com
-
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/