On 2/10/19 8:44 AM, James Bottomley wrote: > On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson wrote: >> On Sat, Feb 9, 2019 at 7:19 PM James Bottomley >> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > [...] >>> I think the reason for this is that the block mq path doesn't feed >>> the kernel entropy pool correctly, hence the need to install an >>> entropy gatherer for systems that don't have other good random >>> number sources. >> >> That does sound plausible, I admit I didn't even consider the >> possibility that the old block I/O path also was an entropy source. > > In theory, the new one should be as well since the rotational entropy > collector is on the SCSI completion path. I'd seen the same problem > but had assumed it was something someone had done to our internal > entropy pool and thus hadn't bisected it. The difference is that the old stack included ADD_RANDOM by default, so this check: if (blk_queue_add_random(q)) add_disk_randomness(req->rq_disk); in scsi_end_request() would be true, and we'd add the randomness. For sd, it seems to set it just fine for non-rotational drives. Could this be because other devices don't? Maybe the below makes a difference. diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 6d65ac584eba..60e029911755 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1881,6 +1881,7 @@ struct request_queue *scsi_mq_alloc_queue(struct scsi_device *sdev) sdev->request_queue->queuedata = sdev; __scsi_init_queue(sdev->host, sdev->request_queue); blk_queue_flag_set(QUEUE_FLAG_SCSI_PASSTHROUGH, sdev->request_queue); + blk_queue_flag_set(QUEUE_FLAG_ADD_RANDOM, sdev->request_queue); return sdev->request_queue; } -- Jens Axboe
