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, 10 Sep 2010 15:24:04 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, agk@...hat.com, jaxboe@...ionio.com,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-raid@...r.kernel.org, dm-devel@...hat.com, hch@....de,
	konishi.ryusuke@....ntt.co.jp, James.Bottomley@...e.de,
	tytso@....edu, chris.mason@...cle.com, swhiteho@...hat.com,
	vst@...b.net, jack@...e.cz, rwheeler@...hat.com, hare@...e.de,
	neilb@...e.de, rusty@...tcorp.com.au, mst@...hat.com,
	k-ueda@...jp.nec.com
Subject: Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based
 dm

On Fri, Sep 10 2010 at  3:05pm -0400,
Mikulas Patocka <mpatocka@...hat.com> wrote:

> 
> 
> On Fri, 10 Sep 2010, Mike Snitzer wrote:
> > And in fact, this first patch basically is as minimal as it gets
> > relative to bio-based DM's conversion to FLUSH+FUA.
> > 
> > Please direct your energy and talent in a positive way rather than
> > starting a potential flame.
> > 
> > Thanks,
> > Mike
> 
> I don't want to flame. I mean this:
> 
> * person X writes a patch P.
> * person Y reads P, sees that the condition C is true and writes patch Q 
> that dependes on condition C.
> * person X changes a patch P, so that the patch is correct but condition C 
> is no longer true.
> 
> Now, there is a bug in the patch Q and NEITHER X NOR Y can find out about 
> that bug.
> 
> That's why parallel development doesn't work.
> 
> If you develop on things in the kernel, it is different.
> * person X writes a patch P and puts it in the kernel.
> * person Y reads the kernel code, sees that the condition C is true and 
> writes a patch Q that assumes that the condition C is true. He puts this 
> patch to the kernel too.
> * person X wants to change his code so that the condition C isn't true, 
> but it is now his responsibility to search the rest of the kernel to see 
> if it depends on the condition C. He searches the code and finds Q.
> 
> This is not a flamewar, just a technical explanation, why I don't want to 
> develop on interfaces that are not in the kernel.

We're reasonable people and can certainly prevent a flamewar but what
you're doing is an elaborate distraction.  The energy it took you to
write and reason through your logic above could've been used to just
review the DM FLUSH+FUA patches.

The various interfaces are hardened now and staged for inclussion in
2.6.37.  Jens has already pulled the entire 40+ patchset into his
for-next branch for wider linux-next testing.

Tejun, Christoph and others have done an amazing job with this
conversion.  The fact that Tejun tackled the heavy lifting of DM's
conversion was unexpected but 100% appreciated (by me and I assume
others).  Please don't dismiss, or misrepresent the status of, this
FLUSH+FUA work.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ