From patchwork Mon Jan 3 14:21:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 530293 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4507AC433EF for ; Mon, 3 Jan 2022 14:23:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231575AbiACOXm (ORCPT ); Mon, 3 Jan 2022 09:23:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233600AbiACOXM (ORCPT ); Mon, 3 Jan 2022 09:23:12 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96689C06179B; Mon, 3 Jan 2022 06:23:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 14262CE1105; Mon, 3 Jan 2022 14:23:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF146C36AEB; Mon, 3 Jan 2022 14:23:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1641219788; bh=q1y2rSOGp+yLXZH6g3odHuz0Pl79A/Cg7YjxsfUUMMk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ArsvPRyUyfdnlf56CVAEKp2QktJhUttrsW6/OFlorzIF7K2qUQFOQUJNgfaAdM0Sl UIxNafzhVyV1WbClLKEYMg7fRyncS7DaBCSi5qFObrpFeBZ1apw9dBLAkajn+ui8mK azDzQegjsP3URS7Gw7DYvzUFlMtH7UIdD3crDPyc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Matt Wang , "Martin K. Petersen" , Vishal Bhakta , VMware PV-Drivers , "James E.J. Bottomley" , linux-scsi@vger.kernel.org, Alexey Makhalov , Shmulik Ladkani Subject: [PATCH 4.14 15/19] scsi: vmw_pvscsi: Set residual data length conditionally Date: Mon, 3 Jan 2022 15:21:32 +0100 Message-Id: <20220103142052.567975725@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220103142052.068378906@linuxfoundation.org> References: <20220103142052.068378906@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org From: Alexey Makhalov commit 142c779d05d1fef75134c3cb63f52ccbc96d9e1f upstream. The PVSCSI implementation in the VMware hypervisor under specific configuration ("SCSI Bus Sharing" set to "Physical") returns zero dataLen in the completion descriptor for READ CAPACITY(16). As a result, the kernel can not detect proper disk geometry. This can be recognized by the kernel message: [ 0.776588] sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512. The PVSCSI implementation in QEMU does not set dataLen at all, keeping it zeroed. This leads to a boot hang as was reported by Shmulik Ladkani. It is likely that the controller returns the garbage at the end of the buffer. Residual length should be set by the driver in that case. The SCSI layer will erase corresponding data. See commit bdb2b8cab439 ("[SCSI] erase invalid data returned by device") for details. Commit e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length") introduced the issue by setting residual length unconditionally, causing the SCSI layer to erase the useful payload beyond dataLen when this value is returned as 0. As a result, considering existing issues in implementations of PVSCSI controllers, we do not want to call scsi_set_resid() when dataLen == 0. Calling scsi_set_resid() has no effect if dataLen equals buffer length. Link: https://lore.kernel.org/lkml/20210824120028.30d9c071@blondie/ Link: https://lore.kernel.org/r/20211220190514.55935-1-amakhalov@vmware.com Fixes: e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length") Cc: Matt Wang Cc: Martin K. Petersen Cc: Vishal Bhakta Cc: VMware PV-Drivers Cc: James E.J. Bottomley Cc: linux-scsi@vger.kernel.org Cc: stable@vger.kernel.org Reported-and-suggested-by: Shmulik Ladkani Signed-off-by: Alexey Makhalov Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/vmw_pvscsi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/vmw_pvscsi.c +++ b/drivers/scsi/vmw_pvscsi.c @@ -578,9 +578,12 @@ static void pvscsi_complete_request(stru * Commands like INQUIRY may transfer less data than * requested by the initiator via bufflen. Set residual * count to make upper layer aware of the actual amount - * of data returned. + * of data returned. There are cases when controller + * returns zero dataLen with non zero data - do not set + * residual count in that case. */ - scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen); + if (e->dataLen && (e->dataLen < scsi_bufflen(cmd))) + scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen); cmd->result = (DID_OK << 16); break;