linux-kernel - Re: [PATCH 0/1] random vs blk-mq

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: <535A6EC7.10305@kernel.dk>
Date:	Fri, 25 Apr 2014 08:18:47 -0600
From:	Jens Axboe <axboe@...nel.dk>
To:	Christoph Hellwig <hch@...radead.org>,
	Theodore Ts'o <tytso@....edu>
CC:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH 0/1] random vs blk-mq

On 04/25/2014 01:36 AM, Christoph Hellwig wrote:
> A tester found out that we need add_disk_randomness for my scsi-mq
> branch.  The patch applied exports add_disk_randomness so that modular
> scsi still works with a driver that either uses the low-level I/O
> completion routines for the old block layer, or blk-mq, and I'd love
> to get this in through Jens' tree which has all the other block work
> scsi-mq requires.
> 
> But this also brings up an interesting question:  blk-mq currently
> does not set QUEUE_FLAG_ADD_RANDOM in the default queue flags, so
> simply converting a driver to blk-mq will mean it stops contributing
> to the random pool.  Do we need a more fine grained way to control
> this, especially for SCSI?

Or, we could just fix the horribly slow pool mix and have it always be
on if it's "free", or almost free. Perhaps just default to on for
rotating devices, that'd lessen the impact.

-- 
Jens Axboe

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