From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Subject: Re: [PATCH v2 2/6] esp_scsi: Track residual for PIO transfers Date: Mon, 15 Oct 2018 09:14:18 +1100 (AEDT) Message-ID: References: <11a3a80e74a006040460fa051747e6a79c6382ce.1539497520.git.fthain@telegraphics.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Geert Uytterhoeven Cc: "James E.J. Bottomley" , "Martin K. Petersen" , Michael Schmitz , Hannes Reinecke , scsi , linux-m68k , Linux Kernel Mailing List List-Id: linux-scsi@vger.kernel.org On Sun, 14 Oct 2018, Geert Uytterhoeven wrote: > > > Fixes: 6fe07aaffbf0 > > Fixes: 6fe07aaffbf0 ("[SCSI] m68k: new mac_esp scsi driver") > Fixed. > > Tested-by: Stan Johnson > > Signed-off-by: Finn Thain > > Tested-by: Michael Schmitz > > > --- a/drivers/scsi/esp_scsi.h > > +++ b/drivers/scsi/esp_scsi.h > > @@ -540,6 +540,8 @@ struct esp { > > > > void *dma; > > int dmarev; > > + > > + int send_cmd_residual; > > unsigned int? > My first thought was to use u32, same as esp_count. But it turns out that the end result really is an int -- static int esp_data_bytes_sent(struct esp *esp, struct esp_cmd_entry *ent, struct scsi_cmnd *cmd) { int fifo_cnt, ecount, bytes_sent, flush_fifo; ... bytes_sent = esp->data_dma_len; bytes_sent -= ecount; bytes_sent -= esp->send_cmd_residual; ... return bytes_sent; } Apparently over/underflow is a real possibility, because there is a test for this in esp_process_event(). -- > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >