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]

Date:	Sun, 25 Nov 2012 21:55:20 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	torvalds@...ux-foundation.org
Cc:	Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate
 UAPI

On Mon, Nov 26, 2012 at 11:28:14AM +1100, Dave Chinner wrote:
> fs: revert commit bbdd6808 to fallocate UAPI
> 
> From: Dave Chinner <dchinner@...hat.com>
> 
> Commit bbdd6808 ("fs: reserve fallocate flag codepoint") changes the
> fallocate(2) syscall interface. The flag that is reserved by this
> commit is for functionality that has previously been NAKed on the
> -fsdevel mailing list, and so exists out-of-tree.

Hi Linus,

It doesn't change the interface or break anything; it just reserves a
bit so that out-of-tree patches don't collide with future allocations.
There are significant usages of this bit within Google and Tao Bao.
It is true that there has been significant pushback about adding this
functionality on linux-fsdevel; I find it personally frustrating that
in effect, if enough people scream, they can veto an optional feature
that might only be implemented by a single file system.

It's not like there is any shortage of flag bits, so what's the harm
of reserving the bit?

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