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: <465F15ED.1070304@cfl.rr.com>
Date:	Thu, 31 May 2007 14:37:33 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	device-mapper development <dm-devel@...hat.com>,
	David Chinner <dgc@....com>, Tejun Heo <htejun@...il.com>,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	Andreas Dilger <adilger@...sterfs.com>,
	Stefan Bader <Stefan.Bader@...ibm.com>
Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices,
 filesystems, and dm/md.

Jens Axboe wrote:
> No Stephan is right, the barrier is both an ordering and integrity
> constraint. If a driver completes a barrier request before that request
> and previously submitted requests are on STABLE storage, then it
> violates that principle. Look at the code and the various ordering
> options.

I am saying that is the wrong thing to do.  Barrier should be about 
ordering only.  So long as the order they hit the media is maintained, 
the order the requests are completed in can change.  barrier.txt bears 
this out:

"Requests in ordered sequence are issued in order, but not required to 
finish in order.  Barrier implementation can handle out-of-order 
completion of ordered sequence.  IOW, the requests MUST be processed in 
order but the hardware/software completion paths are allowed to reorder 
completion notifications - eg. current SCSI midlayer doesn't preserve 
completion order during error handling."


-
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