Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp848478pxf; Thu, 1 Apr 2021 15:37:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYVww+rHVcPFg+JTiOOtaqdWZn6pzS+LuPTmR0alFEBjZIFiUCyHo6GxN9xxH2Ph+2dtUt X-Received: by 2002:a17:906:f896:: with SMTP id lg22mr11102277ejb.124.1617316621811; Thu, 01 Apr 2021 15:37:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617316621; cv=none; d=google.com; s=arc-20160816; b=Ttta674oTSpVOg5y3lUSY4KVWtnOyu2KZL2h4taqg0/KfZmaWvcQXhG2e4NllXLfGA yEjL99fMIippHAEYOrksc9Al8L0ezyY99kqA/KvvWE4CCdY0kUN7Y7zpboq+PO5H6YA4 L1kSFJk0UUGrj55kTXTSVMcvqXTIsQkx9+lYuaEK8FD4/xIBSQOfCU80WuBHsusIlabZ p5kC0XfMzdeyP9Y+BeMl6r1UffeSYobnwQ5sx+Tofpbu/fiasov1ycwgr4bbrivI832A WhgQXyxghkZ3JpJYVuYMf16ife4K216/txMJ5tzB4jmkq2nd6S+nNkeKLArA7fVs03YD KLkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Fj85qQK7dbFMVrWc6drYDzKb296D9FbiiC583NFbWrY=; b=Fhflsz7wxA0wkubV2TZaqsBA07/DTUw9wOT/Vz1CCgcQfD1hjQtIuYchuV16tNimWu A9lpyw5ewB/+AauEkSxgofh0wgXrBpHuGWDtMruMbsH+82zKjjvKBNJtOKKhZHrxE/DW rDLGjNBpkOfznH10H1z1BaN9X6Ky2OgxEupNpWS3aqOnaawaJJYLcE0r/5SFcwSpVdIt PuXiD3QEhSO0Je2PZ9Ba0/FIid9ArqxsF7YgXQyhcqHPFO47HAooWhSjzavfbnEfr3HL OkOrFiyiHVdQgrXKoHjubP81yLlWqQrCwcUpVfb6iYUiFlde5KwR6gwbAcH2OseWfOSY Wl3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IQUVaebi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u27si4835765ejj.726.2021.04.01.15.36.37; Thu, 01 Apr 2021 15:37:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IQUVaebi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234287AbhDAWfL (ORCPT + 99 others); Thu, 1 Apr 2021 18:35:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233789AbhDAWfK (ORCPT ); Thu, 1 Apr 2021 18:35:10 -0400 Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5AD0C0613E6 for ; Thu, 1 Apr 2021 15:35:10 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id c24-20020a9d6c980000b02902662e210895so2998607otr.9 for ; Thu, 01 Apr 2021 15:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Fj85qQK7dbFMVrWc6drYDzKb296D9FbiiC583NFbWrY=; b=IQUVaebifeGyZummO+FyMc4HYoA8epMMse84C7n0U0fsWyoFXP8OCKn24+g3ihYgpS np8crOUCKDBih1v8z55ihhICh3Lz/y6TMC/rZnJCa5G+WQL4sqoqNRSb6MN3GrYCTws4 +IoGC5zMHomwEa7+19+dNME/iP3tgB43k4CwrEIeGlBgWLDWcQqFAVkue2qiA0GNQdJt AHKUQaeSY+/qwp0/BkjMiHzrLSPEvgvkbALGjI/E8t1dgvx3H8Bj9sYvaH3n1r4F/mLr OBrMi/+R2cHWKp/OgoVZBf/HMP6i/cm994PjeeHpenAUOmRWzCeJFC+oxq/DzB82kuoC LbJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Fj85qQK7dbFMVrWc6drYDzKb296D9FbiiC583NFbWrY=; b=coHAkdrtF8lvkQ28avljyGDuGat7pBlQ5dTrgfXGdqoaZE/5ZFryCfvKyVjjuseMPG 3o0gGUBt0vwoaa5GOJt9//k6etMLj8/2SaE7FuodhzYZ9Qi2oQFduokiicM0zsYWewE4 QnnfnvJHNrEGOywAF/oZ3cTwq/BKzgcjlNiqfiFCduu6F1ai/48fqdY54tMmAClPEzGl v0NcIC6bVX+K+eT9rLXUlliLQeDP4rS+dIc4kK1RgMPzR80lFpx6eSlGyr5Jps+9SyHk 5JeawicXGEWlc96smvBz/RYJHqWUpsG2JQg3iptHAD8v1mXdbiIv8gn0RDO7N+rGCqso RtIw== X-Gm-Message-State: AOAM532jJzqJhbr7Jhdj/Q/56NAFkVRRyByatNikh0IjVLjFCijlR9mK MC90IuEhq/hcbjc7VPuyV2nwhZkMyrGfTIgvmUlWSQ== X-Received: by 2002:a9d:620a:: with SMTP id g10mr8664398otj.335.1617316510065; Thu, 01 Apr 2021 15:35:10 -0700 (PDT) MIME-Version: 1.0 References: <20210318225632.2481291-1-jollys@google.com> <5e7ea537-86ab-f654-1df4-765364116e18@huawei.com> <993f97da-01f0-262b-3fbe-66fa1769698a@huawei.com> In-Reply-To: From: Jolly Shah Date: Thu, 1 Apr 2021 15:34:58 -0700 Message-ID: Subject: Re: [PATCH v2] scsi: libsas: Reset num_scatter if libata mark qc as NODATA To: luojiaxing Cc: John Garry , Jason Yan , jejb@linux.ibm.com, martin.petersen@oracle.com, a.darwish@linutronix.de, dan.carpenter@oracle.com, b.zolnierkie@samsung.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Luojiaxing, On Mon, Mar 22, 2021 at 1:41 AM luojiaxing wrote: > > > On 2021/3/20 20:14, John Garry wrote: > > On 19/03/2021 01:43, Jason Yan wrote: > >> > >> > >> =E5=9C=A8 2021/3/19 6:56, Jolly Shah =E5=86=99=E9=81=93: > >>> When the cache_type for the scsi device is changed, the scsi layer > >>> issues a MODE_SELECT command. The caching mode details are communicat= ed > >>> via a request buffer associated with the scsi command with data > >>> direction set as DMA_TO_DEVICE (scsi_mode_select). When this command > >>> reaches the libata layer, as a part of generic initial setup, libata > >>> layer sets up the scatterlist for the command using the scsi command > >>> (ata_scsi_qc_new). This command is then translated by the libata laye= r > >>> into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata lay= er > >>> treats this as a non data command (ata_mselect_caching), since it onl= y > >>> needs an ata taskfile to pass the caching on/off information to the > >>> device. It does not need the scatterlist that has been setup, so it > >>> does > >>> not perform dma_map_sg on the scatterlist (ata_qc_issue). > >>> Unfortunately, > >>> when this command reaches the libsas layer(sas_ata_qc_issue), libsas > >>> layer sees it as a non data command with a scatterlist. It cannot > >>> extract the correct dma length, since the scatterlist has not been > >>> mapped with dma_map_sg for a DMA operation. When this partially > >>> constructed SAS task reaches pm80xx LLDD, it results in below warning= . > >>> > >>> "pm80xx_chip_sata_req 6058: The sg list address > >>> start_addr=3D0x0000000000000000 data_len=3D0x0end_addr_high=3D0xfffff= fff > >>> end_addr_low=3D0xffffffff has crossed 4G boundary" > >>> > >>> This patch updates code to handle ata non data commands separately so > >>> num_scatter and total_xfer_len remain 0. > >>> > >>> Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if > >>> libata marks qc as NODATA") > >>> Signed-off-by: Jolly Shah > > > > Reviewed-by: John Garry > > > > @luojiaxing, can you please test this? > > > Sure, let me take a look, and reply the test result here later > Wanted to follow up on test results. Any updates? Thanks, Jolly > > Thanks > > Jiaxing > > > > > >>> --- > >>> v2: > >>> - reorganized code to avoid setting num_scatter twice > >>> > >>> drivers/scsi/libsas/sas_ata.c | 9 ++++----- > >>> 1 file changed, 4 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/drivers/scsi/libsas/sas_ata.c > >>> b/drivers/scsi/libsas/sas_ata.c > >>> index 024e5a550759..8b9a39077dba 100644 > >>> --- a/drivers/scsi/libsas/sas_ata.c > >>> +++ b/drivers/scsi/libsas/sas_ata.c > >>> @@ -201,18 +201,17 @@ static unsigned int sas_ata_qc_issue(struct > >>> ata_queued_cmd *qc) > >>> memcpy(task->ata_task.atapi_packet, qc->cdb, > >>> qc->dev->cdb_len); > >>> task->total_xfer_len =3D qc->nbytes; > >>> task->num_scatter =3D qc->n_elem; > >>> + task->data_dir =3D qc->dma_dir; > >>> + } else if (qc->tf.protocol =3D=3D ATA_PROT_NODATA) { > >>> + task->data_dir =3D DMA_NONE; > >> > >> Hi Jolly & John, > >> > >> We only set DMA_NONE for ATA_PROT_NODATA, I'm curious about why > >> ATA_PROT_NCQ_NODATA and ATAPI_PROT_NODATA do not need to set DMA_NONE? > > > > So we can see something like atapi_eh_tur() -> ata_exec_internal(), > > which is a ATAPI NONDATA and has DMA_NONE, so should be ok. > > > > Other cases, like those using the xlate function on the qc for > > ATA_PROT_NCQ_NODATA, could be checked further. > > > > For now, we're just trying to fix the fix. > > > >> > >> Thanks, > >> Jason > >> > >> > >>> } else { > >>> for_each_sg(qc->sg, sg, qc->n_elem, si) > >>> xfer +=3D sg_dma_len(sg); > >>> task->total_xfer_len =3D xfer; > >>> task->num_scatter =3D si; > >>> - } > >>> - > >>> - if (qc->tf.protocol =3D=3D ATA_PROT_NODATA) > >>> - task->data_dir =3D DMA_NONE; > >>> - else > >>> task->data_dir =3D qc->dma_dir; > >>> + } > >>> task->scatter =3D qc->sg; > >>> task->ata_task.retry_count =3D 1; > >>> task->task_state_flags =3D SAS_TASK_STATE_PENDING; > >>> > >> . > > > > > > . > > >