From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f52.google.com (mail-dl1-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AFB6382F28 for ; Sun, 12 Apr 2026 15:24:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776007492; cv=none; b=TxADi/5CQp0a8ZuT7pcFfmcNmtwaaHq/CvU+ADFUN8DVfgxqeMf6WX/oIWFvXijEpYEsLYJCyAI23v7vxz24L7jx0RKcJWI8BFbgM9xVUE9rGyBBaM6F6vFfegVqRfeCDpjcVMam1Q8oMO8P7gKFu35H4PSPj1mi6JnRTDHbx2o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776007492; c=relaxed/simple; bh=XgP3KwC58zb3/opTPFHRLxrELBJ3ntPRPoey+cXXTPc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q5R2mLaKLFXfZl4XA89GlzbGaz70dsURFQWV+Yti2DvrWCe35hOUldl22b7AaIdmXZseG2VrrwqSh1HeIHzrwM+gkJVKrAtu6sXZxFwg07RZguWn+eVxXT4f4wAoi/lNc3dGp7ngPC40f5Slpc/M29HdbO1emILAsfKZlTigH8A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=kRjBf64B; arc=none smtp.client-ip=74.125.82.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="kRjBf64B" Received: by mail-dl1-f52.google.com with SMTP id a92af1059eb24-1270f10a774so28217c88.1 for ; Sun, 12 Apr 2026 08:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776007485; x=1776612285; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hxVEU8M9tLLC0GDPV7iNVKeKt6wxmMr9DFDIGX2wN90=; b=kRjBf64BDWzh7DgbEVlOGAtaY/CcaBWlGhdNobZK3zHHe3JUt3KjWzs2asheWQi/SQ HXuScs0sO54saCU+20fHNY0/XmWLh7xAo4MDvYDcmvIwXA2W030NVvywqHbLr3G6op0q acWijT1nY7xqKb3+WbJlFJioYppdJMJB0WFRN0K8KBIlf15txezCcvCXIca17nugQAbl RJ3Okb9lZS7tivFpnf5b0GLDqxF9pC3h2XC3KjahlDTZUGAn8Nlup1MUpHdZibwP8uJe r7Kd+Xs1fNbe4Nz192F1i90Q27rzLGEqKgth3WB4dk52EtxMJG2WKrC/iDt0wioNu+o0 mtoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776007485; x=1776612285; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hxVEU8M9tLLC0GDPV7iNVKeKt6wxmMr9DFDIGX2wN90=; b=XGkIM8lm3mnuZmM2nizZA9LjzM6TfxYtL5OuTpXRvq+ZIpqTXlj4jQse4pMG5NRumV js0WHu+eqn/yzyu4ZHuVGgMYfVzLbgc+8ocgXy+Yqh74CMYvlxXs7g2IogMK4OOCU8nW ulXSlFLKkCASx6ucwawu9buDLNIn5JzlcSXRRYq+7YvzS0tQYBsKNjY7Wa1HyLPVcDcY cJRibA4dMv1gqMj/lPzjQPnmkxlM91mH7odeqTjVFiMBwf2CK1Sny2/tCO7dbpizVYcf g3Iwiayj81RrXIzVbUH+qUkAylY2peZEGKNm3qv+7Z+J2ligEocMQWVS72y05i7PRRgm J40Q== X-Forwarded-Encrypted: i=1; AJvYcCU9o/W7Lskkua4ybt6UlxPGiJhNylWg0IWaDXob4dh3x2wzbLlntHf+TZSXA6kkVAaUuzl6XJSVN7q8kL0=@vger.kernel.org X-Gm-Message-State: AOJu0YxRB5bpQt/ewln5dvQ7/Q6kZBt9qAo59D6MxKbU1Hm5VQyB/ppK O8DmviASpryyu4gXT5csNiysfWCoiO7uRoUHFg2aVGjX6re3DLxnsb67RttjELnbsw== X-Gm-Gg: AeBDiesivldD3c0cNz3x8Wl7h5O28EBX5pioIBqOgZwDmUjS+kzax22iILqKhMS8rHC Ktf0lHrddf17JiLgHpfFs4EbPtjrpCYDFVagdYFwAEN7Ufk9ZRIet/33MdPQknsMpD0LMFoe9Pa NUO8sq2eiq5P5X757GogHhwxitBhKZRIdvlzKbK37XXH7v/jVWYu1FG40YWVWLZChwkBuUsqGGo Sn+9rb8OP1MWIC5Cz/GwntfgMYlmAh/TNLm5vKyjckkX6t7MhEhTg+8LXd8ORmEQiMmuHKPQdyC UIwkP/6vK1xNy0pntCaI3rw6xRKuX542yszNdwrOrml3VYQiaQTcea9e7UU5X1V1c3+80igwLzn wFGODNbItTWbqMeEIPxip8pSavxnKxmGenTFixKvk5bg9ORIiuReyTtaW1eQrlaaqlGvETv2QRC iV0VeljXcshW/GLtINGr8BXbdHL2SelMPpgBbt5h1hKr958heip16MRhm8gCklq9bKiPbkQ2OU X-Received: by 2002:a05:7022:211:b0:12c:3d1c:b317 with SMTP id a92af1059eb24-12c3d1cb56dmr155191c88.2.1776007484428; Sun, 12 Apr 2026 08:24:44 -0700 (PDT) Received: from google.com (91.195.168.34.bc.googleusercontent.com. [34.168.195.91]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2d55faa571csm15163191eec.10.2026.04.12.08.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Apr 2026 08:24:44 -0700 (PDT) Date: Sun, 12 Apr 2026 08:24:39 -0700 From: Igor Pylypiv To: Niklas Cassel Cc: Damien Le Moal , "Martin K. Petersen" , John Garry , Xingui Yang , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ata: libata-scsi: fix requeue of deferred ATA PASS-THROUGH commands Message-ID: References: <20260410231519.951971-1-ipylypiv@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Apr 12, 2026 at 12:42:46PM +0200, Niklas Cassel wrote: > On Fri, Apr 10, 2026 at 04:15:19PM -0700, Igor Pylypiv wrote: > > Commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") > > introduced ata_scsi_requeue_deferred_qc() to handle commands deferred > > during resets or NCQ failures. This deferral logic completed commands > > with DID_SOFT_ERROR to trigger a retry in the SCSI mid-layer. > > > > However, DID_SOFT_ERROR is subject to scsi_cmd_retry_allowed() checks. > > ATA PASS-THROUGH commands sent via SG_IO ioctl have scmd->allowed set > > to zero. This causes the mid-layer to fail the command immediately > > instead of retrying, even though the command was never actually issued > > to the hardware. > > > > Switch to DID_REQUEUE to ensure these commands are inserted back into > > the request queue regardless of retry limits. > > > > Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") > > Signed-off-by: Igor Pylypiv > > --- > > drivers/ata/libata-scsi.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c > > index 3b65df914ebb..0236394900cc 100644 > > --- a/drivers/ata/libata-scsi.c > > +++ b/drivers/ata/libata-scsi.c > > @@ -1692,7 +1692,7 @@ void ata_scsi_requeue_deferred_qc(struct ata_port *ap) > > /* > > * If we have a deferred qc when a reset occurs or NCQ commands fail, > > * do not try to be smart about what to do with this deferred command > > - * and simply retry it by completing it with DID_SOFT_ERROR. > > + * and simply requeue it by completing it with DID_REQUEUE. > > */ > > if (!qc) > > return; > > @@ -1701,7 +1701,7 @@ void ata_scsi_requeue_deferred_qc(struct ata_port *ap) > > ap->deferred_qc = NULL; > > cancel_work(&ap->deferred_qc_work); > > ata_qc_free(qc); > > - scmd->result = (DID_SOFT_ERROR << 16); > > + set_host_byte(scmd, DID_REQUEUE); > > set_host_byte() will set the host byte, but it will keep the status byte > and the ML byte intact. > > By using the assignment operator, I assumed that Damien intentionally > wanted to clear the status byte and the ML byte. > > My point is that using set_host_byte() is a logical change. > If we want to stop clearing the status byte and the ML byte, then I think > that change should be in a separate commit, with a proper motivation/commit > message. > > However, for the fix patch itself, I think we should just do: > - scmd->result = (DID_SOFT_ERROR << 16); > + scmd->result = (DID_REQUEUE << 16); > Hi Niklas, Thank you for pointing it out. I agree. Switching to set_host_byte() is logically a different change from the problem that this commit is fixing. There is no particular need for using set_host_byte(). I'll send a v2 to drop set_host_byte(). Thanks, Igor > > If that is sufficient to fix your observed problem. > > I would also be happy to see a follow up patch that changes to use > set_host_byte(), if there is a motivation that can motivate why that change > is safe/valid. > > > Kind regards, > Niklas