linux-ext4 - Re: [PATCH]ext4: Add checks whether two inodes are different

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] [day] [month] [year] [list]

Message-ID: <20090929144914.GD24383@mit.edu>
Date:	Tue, 29 Sep 2009 10:49:14 -0400
From:	Theodore Tso <tytso@....edu>
To:	Akira Fujita <a-fujita@...jp.nec.com>
Cc:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH]ext4: Add checks whether two inodes are different

On Tue, Sep 29, 2009 at 02:18:39PM +0900, Akira Fujita wrote:
> I thought the argument check (orig and donor inodes are different)
> should be done in mext_check_arguments()

Sometimes separating things into multiple functions can actually make
things harder to understand, since it means you have to jump all over
the file to follow what a particular function is doing.  Sometimes
having a function which is nested deeply in a loop can be made easier
to understand by separating it out into a separate function which is
called once.

Part of the reason why mext_check_arguments() is so huge is because of
all of the ext4_debug() statements.  It's not clear to me they really
all need to be there.  I'd also use EBUSY if the file is a swap file,
so it's easier for the userspace code to understand what is going on
in that case.  For the other many cases where EINVAL is returned,
hopefully that's obvious enough for userspace to figure out without
having to resort to looking to the system debug logs.

       	  	    	       	   	  	- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html