linux-kernel - [PATCH 05/12] scsi/ncr5380: Increase register polling limit

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

Message-Id: <a08485a9098dee87bd5e02010637f2f0683d75d0.1475559357.git.fthain@telegraphics.com.au>
Date:   Tue,  4 Oct 2016 01:40:50 -0400 (EDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     Michael Schmitz <schmitzmic@...il.com>,
        Ondrej Zary <linux@...nbow-software.org>,
        <linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH 05/12] scsi/ncr5380: Increase register polling limit

If NCR5380_poll_politely() is called under irq lock, the polling time
limit is clamped to avoid a spike in interrupt latency. When not under
irq lock, the same polling time limit acts as the worst case delay
between schedule() calls.

During PDMA (under irq lock) I've found that the 10 ms time limit is
sometimes too short, and leads to the error message,
sd 0:0:0:0: [sda] tag#1 macscsi_pread: !REQ and !ACK

This particular target identifies itself as a QUANTUM DAYTONA514S. It
seems to be slower to assert ACK than the other targets I've tested.
This patch solves the problem by increasing the polling timeout.

Signed-off-by: Finn Thain <fthain@...egraphics.com.au>
---
When irqs are disabled, this change will make no difference unless the
driver or target happens to suffer from timeout errors. In the irqs
enabled case, this patch may delay the next call to schedule() by an
additional 5 ms (in all 5380 drivers). Normally that would only happen
for a target selection timeout during a SCSI bus scan, which should not
bother anyone too much.
---
 drivers/scsi/NCR5380.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index ac0daa4..13d7aff 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -253,7 +253,7 @@ struct NCR5380_cmd {
 #define NCR5380_PIO_CHUNK_SIZE		256
 
 /* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA */
-#define NCR5380_REG_POLL_TIME		10
+#define NCR5380_REG_POLL_TIME		15
 
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
-- 
2.7.3