linux-kernel - Re: [PATCH] block: Force sector and nr_sects to device alignment and granularity.

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:	Wed, 12 Mar 2014 15:33:58 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Frank Mayhar <fmayhar@...gle.com>
Cc:	Jens Axboe <axboe@...nel.dk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Theodore Tso <tytso@...gle.com>
Subject: Re: [PATCH] block:  Force sector and nr_sects to device alignment and granularity.

Frank Mayhar <fmayhar@...gle.com> writes:

> On Wed, 2014-03-12 at 14:20 -0400, Jeff Moyer wrote:
>> but you managed to read my mind well enough.  The question is how high
>> up the stack do you put the logic for this?  Is it worth it to duplicate
>> the checks in the OS that are already done on the device?  I don't
>> know.  Martin, do you have an opinion on this?
>
> Well, my opinion (and I suspect that Ted agrees with me to at least some
> extent) is that this is where it should be, i.e. in the block layer, in
> the place that already knows about and deals with alignment and
> granularity.  Sure, you could leave it to the device itself but it seems
> reasonable to take care of this here for two reasons:  First, doing this
> means that if a TRIM is issued it will be successful and the intent of

No, TRIM is advisory, even for well-formed TRIMs.  I guess you could
alter the definition of successful and have a correct statement there.

> the discard will be at least partly satisfied.  Second, we're already
> doing most of the computations and making decisions based on the
> alignment and granularity anyway, so the overhead is pretty negligible
> (and if the discard size goes to zero we short-circuit the process and
> never go to the device at all).

Sure, there's no sense getting information from the device and not using
it.  I guess you've talked me into it.

Cheers,
Jeff
--
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/