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] [day] [month] [year] [list]
Message-ID: <yq1sk8rmqyl.fsf@sermon.lab.mkp.net>
Date:	Tue, 23 Feb 2010 19:12:50 -0500
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Mike Snitzer <snitzer@...hat.com>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] block: warn if blk_stack_limits() undermines atomicity

>>>>> "Mike" == Mike Snitzer <snitzer@...hat.com> writes:

>> Not really.  It'll be issued as one I/O with a smaller LBA count but
>> an identical data payload.

Mike> Can you expand on that a bit?  How does a smaller LBA count relate
Mike> to this?  On a 512b device the 4K data payload would touch more
Mike> LBAs.

Sorry, I had my head stuck in the 4KB case.  More blocks.  My point
being that regardless of the logical block size we'll be issuing a
single command.  The only difference between the two cases is the LBA
count. I.e. the protocol encoding of how much data to transfer.


Mike> In any case, a 4K write to a 512b device is not atomic.

Mike> If you think what I've raised here is overblown then I'd like to
Mike> understand why in more detail.

I'm just playing devil's advocate here.  We have no guarantees that a
512-byte write to a 512-byte device is atomic either.  None.  We've been
trying very hard to get any guarantees out of storage vendors for years
without any luck.  I know that a lot of our stuff operate on the
assumption that sector writes are atomic.  But in a lot of cases they
are not.


Mike> Otherwise all you have is a largely generic warning (as
Mike> blk_stack_limits knows nothing about which devices the provided
Mike> limits belong to).

Yeah, I had a patch at some point that distinguished between the various
error conditions instead of returning -1.  I'll see if I can dig that
up...

-- 
Martin K. Petersen	Oracle Linux Engineering
--
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