linux-kernel - Re: [PATCH v5 01/11] block: make generic_make

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: <yq11tf9hg01.fsf@sermon.lab.mkp.net>
Date:	Tue, 11 Aug 2015 13:49:50 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Kent Overstreet <kent.overstreet@...il.com>
Cc:	Mike Snitzer <snitzer@...hat.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Ming Lin <mlin@...nel.org>, axboe@...com,
	Christoph Hellwig <hch@...radead.org>,
	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>,
	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

>>>>> "Kent" == Kent Overstreet <kent.overstreet@...il.com> writes:

Kent> This kind of logic really doesn't belong in dm

Well it does in this case since the thinp personality actually
provisions and unprovisions space.

But there is a difference between what dm thinp acts on for its own
internal provisioning purposes and what it passes down the stack. I am
really against dropping information anywhere along the path. We don't
round off read/write requests either.

The queue limits were meant as hints to mkfs.* so that on-disk data
structures could be laid out in an aligned and storage friendly way. I
never intended for the hints to affect runtime behavior.

Kent> IMO though it belongs in the driver - if a discard needs to be
Kent> dropped because it's too small and the hardware can't do it, that
Kent> should be the driver's responsibility.

I agree except I really don't want to lop off anything unless the device
locks up if we send it partial blocks. There was an array that had
problems a while back but I believe they have been fixed.

The fundamental premise should be that we pass as comprehensive
information as we can. And the device can then decide to ignore all or
parts of the request. That's fundamentally how things work at the
protocol level in both SCSI and SATA. I don't see any reason why the
Linux I/O stack should behave in a different manner.

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