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:	Mon, 10 Aug 2015 12:22:07 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Mike Snitzer <snitzer@...hat.com>
Cc:	Ming Lin <mlin@...nel.org>, axboe@...com,
	Christoph Hellwig <hch@...radead.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	device-mapper development <dm-devel@...hat.com>,
	Ming Lei <ming.lei@...onical.com>,
	Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>,
	Lars Ellenberg <drbd-dev@...ts.linbit.com>,
	Philip Kelleher <pjk1939@...ux.vnet.ibm.com>,
	Kent Overstreet <kent.overstreet@...il.com>,
	Nitin Gupta <ngupta@...are.org>,
	Ming Lin <ming.l@....samsung.com>,
	Oleg Drokin <oleg.drokin@...el.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Jens Axboe <axboe@...nel.dk>,
	Andreas Dilger <andreas.dilger@...el.com>,
	Geoff Levand <geoff@...radead.org>,
	Jiri Kosina <jkosina@...e.cz>,
	lkml <linux-kernel@...r.kernel.org>, Jim Paris <jim@...n.com>,
	Minchan Kim <minchan@...nel.org>,
	Dongsu Park <dpark@...teo.net>, drbd-user@...ts.linbit.com,
	Joe Thornber <ejt@...hat.com>
Subject: Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios

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

Mike> Shouldn't we also be using MAX_BIO_SECTORS in
Mike> blkdev_issue_write_same (instead of UINT_MAX >> 9)?

The granularity of WRITE SAME is always 1 logical block and there is no
reason to round it down to the next power of two.

+/*
+ * Ensure that max discard sectors doesn't overflow bi_size and hopefully
+ * it is of the proper granularity as long as the granularity is a power
+ * of two.
+ */
+#define MAX_DISCARD_SECTORS ((1U << 31) >> 9)
+

That's fine for SATA since we're already capping at 2TB minus change.
But it means we'll be capping unnecessarily on SCSI. And larger range
counts are impending in SATA as well.

So this goes back to my original comment: The only place there can be a
discard granularity is for SCSI UNMAP. And consequently, we should only
enforce alignment and granularity when that code path is taken in sd.c.

I'm OK with Ming's patch series in general. Let's leave the discard cap
at UINT_MAX and I'll twiddle the rest in SCSI.

Reviewed-by: Martin K. Petersen <martin.petersen@...cle.com>

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