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
| ||
|
Message-ID: <20140622010600.GX9508@dastard> Date: Sun, 22 Jun 2014 11:06:00 +1000 From: Dave Chinner <david@...morbit.com> To: James Bottomley <James.Bottomley@...senPartnership.com> Cc: Daniel Phillips <daniel@...nq.net>, Lukáš Czerner <lczerner@...hat.com>, Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [RFC] Tux3 for review On Sat, Jun 21, 2014 at 12:29:01PM -0700, James Bottomley wrote: > On Thu, 2014-06-19 at 14:58 -0700, Daniel Phillips wrote: > > On Thursday, June 19, 2014 2:26:48 AM PDT, Lukáš Czerner wrote: > > > Let me remind you some more important problems Dave brought up, > > > including page forking: > > > > > > " > > > The hacks around VFS and MM functionality need to have demonstrated > > > methods for being removed. > > > > We already removed 450 lines of core kernel workarounds from Tux3 with an > > approach that was literally cut and pasted from one of Dave's emails. Then > > Dave changed his mind. Now the Tux3 team has been assigned a research > > project to improve core kernel writeback instead of simply adapting the > > approach that is already proven to work well enough. That is a rather > > blatant example of "perfect is the enemy of good enough". Please read the > > thread. > > That's a bit disingenuous: the concern has always been how page forking > interacted with writeback. It's not new, it was one of the major things > brought up at LSF 14 months ago, so you weren't just assigned this. BTW, it's worth noting that reviewers are *allowed* to change their mind at any time during a discussion or during review cycles. Indeed, this occurs quite commonly. It's no different to multiple reviewers disagreeing on what the best way to make the improvement is - sometimes it takes an implementation to solidify opinion on the best approach to solving a problem. i.e. it took an implementation of the writeback hook tailored specifically to tux3's requirements to understand the best way to solve the infrastructure problem for *everyone*. This is how review is supposed to work - take an idea, and refine it into something better that works for everyone. We'd have been stuck way up the creek without a paddle a long time ago if reviewers weren't allowed to change their minds.... Cheers, Dave. -- Dave Chinner david@...morbit.com -- 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/
Powered by blists - more mailing lists