linux-kernel - Re: [PATCH 04/28] OCFS2 is (not) 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]

Date:	Tue, 01 Aug 2006 20:19:55 -0700
From:	Dave Hansen <haveblue@...ibm.com>
To:	Mark Fasheh <mark.fasheh@...cle.com>
Cc:	linux-kernel@...r.kernel.org, viro@....linux.org.uk,
	herbert@...hfloor.at, hch@...radead.org
Subject: Re: [PATCH 04/28] OCFS2 is (not) screwy

On Tue, 2006-08-01 at 19:14 -0700, Mark Fasheh wrote:
> 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.

BTW, some gunk appears to have migrated into this patch that should have
been earlier in the series.  I'll fix that up.

What do you think about the attached patch?  It delays actually touching
i_nlink until the place where saved_nlink used to be zero'd.  I assume
that is the point when we're sure that the inode is going to go away.

Also, instead of just clearing i_nlink for the directory case, I just do
two decrements.  I did that for a few other filesystems as well.  I
guess it can be collapsed to a single operation, but I'm not sure it is
worth the trouble.

Completely and utterly untested, uncompiled patch attached.  Please
consider its filename a formal apology for calling your filesystem
screwy. :)

It might also be worth putting the 'double decrement i_nlink if it is a
directory' behavior in libfs.c.  It appears to be pretty common logic
around the different filesystems.

Thanks for the thorough review!

-- Dave

View attachment "ocfs-is-not-screwy.patch" of type "text/x-patch" (2018 bytes)