linux-kernel - RE: [Regression] fstrim hangs on Hyper-V: caused by "block: improve handling of the magic discard payload"

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] [day] [month] [year] [list]

Date:   Thu, 12 Jan 2017 16:39:27 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Christoph Hellwig <hch@....de>
CC:     "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        Jens Axboe <axboe@...com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        KY Srinivasan <kys@...rosoft.com>,
        "Chris Valean (Cloudbase Solutions SRL)" <v-chvale@...rosoft.com>
Subject: RE: [Regression] fstrim hangs on Hyper-V: caused by "block:    improve
 handling of the magic discard payload"

> From: Christoph Hellwig [mailto:hch@....de]
> Sent: Thursday, January 12, 2017 23:53
> To: Dexuan Cui <decui@...rosoft.com>
> Cc: Christoph Hellwig <hch@....de>; linux-block@...r.kernel.org; Jens Axboe
> <axboe@...com>; Vitaly Kuznetsov <vkuznets@...hat.com>; linux-
> kernel@...r.kernel.org; KY Srinivasan <kys@...rosoft.com>; Chris Valean
> (Cloudbase Solutions SRL) <v-chvale@...rosoft.com>
> Subject: Re: [Regression] fstrim hangs on Hyper-V: caused by "block: improve
> handling of the magic discard payload"
> 
> Can you check if this debug printk triggers for the discard commands?
> 
> ---
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 888e16e..7ab7d08 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1031,6 +1031,10 @@ static void storvsc_command_completion(struct
> storvsc_cmd_request *cmd_request,
>  			data_transfer_length = 0;
>  	}
> 
> +	if (cmd_request->payload->range.len != data_transfer_length)
> +		printk_ratelimited("request len: %u, transfer len: %u\n",
> +			cmd_request->payload->range.len,
> +			data_transfer_length);
>  	scsi_set_resid(scmnd,
>  		cmd_request->payload->range.len - data_transfer_length);
> 

// I fixed the small building issue (data_transfer_length  ==>  vm_srb->data_transfer_length).

No, the printk doesn't trigger for fstrim.

It does trigger at the early boot phase, though.

# dmesg |grep len:
[    0.000000] log_buf_len: 134217728 bytes
[    7.073423] request len: 255, transfer len: 12
[    7.084937] request len: 255, transfer len: 52
[    7.121728] request len: 64, transfer len: 12
[    7.121915] request len: 64, transfer len: 12
[    7.123180] request len: 64, transfer len: 12
[    7.123367] request len: 64, transfer len: 12
[    7.127193] request len: 64, transfer len: 12
[    7.127350] request len: 64, transfer len: 12
[    7.178930] request len: 255, transfer len: 12
[    7.179045] request len: 255, transfer len: 52

-- Dexuan