linux-kernel - Re: [PATCH] block: correctly fallback for zeroout

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: <20160602165813.GA18527@shli-mbp.local>
Date:	Thu, 2 Jun 2016 09:58:13 -0700
From:	Shaohua Li <shli@...com>
To:	Sitsofe Wheeler <sitsofe@...il.com>, <axboe@...com>
CC:	<linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<snitzer@...hat.com>, <axboe@...com>, <martin.petersen@...cle.com>,
	<Kernel-team@...com>
Subject: Re: [PATCH] block: correctly fallback for zeroout

On Sat, May 28, 2016 at 10:27:55AM +0100, Sitsofe Wheeler wrote:
> On Sat, May 28, 2016 at 08:55:43AM +0000, Sitsofe Wheeler wrote:
> > On Thu, May 26, 2016 at 11:08:14AM -0700, Shaohua Li wrote:
> > > blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> > > fallback to regular write. The problem is discard/writesame doesn't
> > > return error for -EOPNOTSUPP, then zeroout can't do fallback and leave
> > > disk data not changed. zeroout should have guaranteed zero-fill
> > > behavior.
> > 
> > It sounds like at least this patch should go in so BLKZEROOUT can always
> > fall back (since those zeros are essential) but it would still be nice
> > to see the disabling of write same being copied up to md device's
> > write_same_max_bytes so everyone knows not to try using it in the future
> > but perhaps someone will say "what if I re-enable it on the device
> > below?" etc.
> 
> I've tested Shaohua's original patch on top of Linus' tree and even
> without the suggested changes (above and below) it at least resolves the
> success being returned but data not being zeroed (with both PVSCSI and
> scsi_debug underlying devices) issue so:
> 
> Tested-by: Sitsofe Wheeler <sitsofe@...oo.com>

Jens,

any chance you could merge this one? I'll fix the MD part later and make sure
write_same_max_bytes sets to 0 after IO failure.

Thanks,
Shaohua