linux-kernel - Re: [PATCH] Update WRITE_SAME timeout in sd_setup_discard

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]

Date:	Thu, 11 Aug 2016 22:08:33 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Shaun Tancheff <shaun@...cheff.com>
Cc:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	"James E . J . Bottomley" <jejb@...ux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@...cle.com>,
	Josh Bingaman <josh.bingaman@...gate.com>,
	Shaun Tancheff <shaun.tancheff@...gate.com>
Subject: Re: [PATCH] Update WRITE_SAME timeout in sd_setup_discard_cmnd

>>>>> "Shaun" == Shaun Tancheff <shaun@...cheff.com> writes:

Shaun,

Shaun> In sd_setup_discard_cmnd() there are a some discard methods that
Shaun> fall back to using WRITE_SAME. It appears that those paths using
Shaun> WRITE_SAME should also use the SD_WRITE_SAME_TIMEOUT instead of
Shaun> the default SD_TIMEOUT.

The expectation is that the UNMAP variants update a translation table of
some sort in close to constant time. Potentially with some head and tail
zeroing on media. And should therefore easily fall within the 30s limit.

But you have a point wrt. SD_LBP_ZERO. It was used for one particular
type of array that did zero block detection (and thus didn't actually
write anything either). I don't think anybody is using this mode of
operation anymore since thin provisioning has been formalized in T10 for
quite a while. But I'd be OK with a patch that uses
SD_WRITE_SAME_TIMEOUT for that particular code path.

-- 
Martin K. Petersen	Oracle Linux Engineering