linux-kernel - Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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: <20121205163303.GG18885@thunk.org>
Date:	Wed, 5 Dec 2012 11:33:03 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Martin Steigerwald <Martin@...htvoll.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate
 UAPI

On Wed, Dec 05, 2012 at 05:18:43PM +0100, Martin Steigerwald wrote:
> Dave provided technical reasons.
> 
> First in the patch description and then in:
> 
> https://lkml.org/lkml/2012/11/26/700

There were no technical reasons.  We are only reserving a bit.  And
different file systems don't support all of the various different
fallocate flags already --- for example, not all file systems support
the punch system call.

Yes, I could create an entrely new ioctl() that looks just like
fallocate, but supports the extra bit, just so that Dave and others
don't have to be offended about the existence of that extra bit ---
but Linus (and others) have considered ioctl()'s evil, since there is
no type checking, and it's just silly to create a separate interface
just because somebody doesn't think some other file system shouldn't
implement a particular feature --- especially since it's not like
we're have any kind of shortage of bits in the fallocate field.

Heck, I probably have more to complain about with the inode flags
field, which were originally created specifically for ext2/3/4, and
which has since been grabbed for use by other file systems, including
btrfs.  You haven't heard me kvetching because btrfs has grabbed
btrfs-specific inode flags for nocow and notail... no one even bother
to try to get it past the fs-devel shed painting crew before *those*
bits were allocated --- and I am absolutely fine with that.

     	  	    	      	 	    - Ted
--
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/