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:	Fri, 7 Dec 2012 14:30:19 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ric Wheeler <rwheeler@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Martin Steigerwald <Martin@...htvoll.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Chinner <david@...morbit.com>,
	Theodore Ts'o <tytso@....edu>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate
 UAPI

On Fri, Dec 07, 2012 at 10:18:00AM -0800, Linus Torvalds wrote:
> 
> And that's _fine_. Once you have actual technical arguments ("I'd like to 
> re-appropriate that bit, because xyzzy") you have real and valid 
> arguments, and it would be easy to then do the sane "let's just use the 
> bit for something more worthy" thing. But even then it's nice to have the 
> knowledge about what the implications of such use would be, for chrissake!

First I want to say that I don't really give a crap about this bit, and
whether or not it's been merged or not. But I think Ric did have one
valid point:

>> I would prefer to fix the performance issue in ext4 rather than add an
>> interface that has no actual users of the actual feature - it exists
>> for applications that want to avoid an unfortunate performance hit
>> from something that we could work around.

This is similar to the preemptible big kernel lock. The BKL has been an
issue for almost everyone, and a really big one for the real-time
folks. But because it was converted into a preemtible lock, it was
dropped low on the priority list of things to get fixed. But it wasn't
until you reverted this code to kick our ass into gear to go about and fix
the issue.

How is this similar? By adding this bit, we removed incentive from a
group of developers that have the means to fix the real issue at hand
(the performance problem with ext4). Thus, it means that they have a work
around that's good enough for them, but the rest of us suffer.

Sure, they could just modify their kernel to keep this bit, but as it
wouldn't be reserved, they would have to worry about colisions in the
future. Thus the incentive to fix the problem at hand. Just like we had
the preempt BKL in the real-time patch, but it was just better to get it
fixed in mainline. Thanks to Frederic that started the work, and then Arnd
that finished it, we no longer have that nasty lock around to deal with.

You were very wise to revert the preemptible BKL, as I believe we
probably would still have BKL in the kernel if you didn't do that. Maybe
reverting this bit might do the same thing? Maybe not. It's your call.

-- Steve

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