linux-kernel - Re: swiotlb default size (64 MB) too small?

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: <tkrat.9e61b4a2f7087aca@s5r6.in-berlin.de>
Date:	Tue, 27 Jan 2009 18:03:40 +0100 (CET)
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux1394-devel@...ts.sourceforge.net
cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: swiotlb default size (64 MB) too small?

On 27 Jan, FUJITA Tomonori wrote at LSML and LKML:
[I wrote]
>> > *) The report does not sound like there was a DMA mappig leak caused by
>> > copying between usb-storage and firewire-sbp2.  Else he would have hit
>> > the problem again even with increased swiotlb default size.

> Hmm, we don't have leak here?
> 
> =
> From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
> Subject: [PATCH] fw-sbp2: fix dma mapping leak on the failure path
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
> ---
>  drivers/firewire/fw-sbp2.c |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/firewire/fw-sbp2.c b/drivers/firewire/fw-sbp2.c
> index e88d506..d40910d 100644
> --- a/drivers/firewire/fw-sbp2.c
> +++ b/drivers/firewire/fw-sbp2.c
> @@ -1491,8 +1491,18 @@ static int sbp2_scsi_queuecommand(struct scsi_cmnd *cmd, scsi_done_fn_t done)
>  	orb->base.request_bus =
>  		dma_map_single(device->card->device, &orb->request,
>  			       sizeof(orb->request), DMA_TO_DEVICE);
> -	if (dma_mapping_error(device->card->device, orb->base.request_bus))
> +	if (dma_mapping_error(device->card->device, orb->base.request_bus)) {
> +		if (scsi_sg_count(cmd)) {
> +			dma_unmap_sg(device->card->device, scsi_sglist(cmd),
> +				     scsi_sg_count(cmd),
> +				     cmd->sc_data_direction);
> +			dma_unmap_single(device->card->device,
> +					 orb->page_table_bus,
> +					 sizeof(orb->page_table),
> +					 DMA_TO_DEVICE);
> +		}
>  		goto out;
> +	}
>  
>  	sbp2_send_orb(&orb->base, lu, lu->tgt->node_id, generation,
>  		      lu->command_block_agent_address + SBP2_ORB_POINTER);

Yes, we do have a leak there.  Thanks a lot for checking the code.

There is one thing missing in the fix:  Even with scsi_sg_count(cmd) !=
0, there is sometimes no orb->page_table to unmap.  It's when the
scatterlist was mapped into a single physical segment.


From: Stefan Richter <stefanr@...6.in-berlin.de>
Subject: firewire: sbp2: fix DMA mapping leak on the failure path

Reported-by: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
who also provided a first version of the fix.

Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

Index: linux/drivers/firewire/fw-sbp2.c
===================================================================
--- linux.orig/drivers/firewire/fw-sbp2.c
+++ linux/drivers/firewire/fw-sbp2.c
@@ -1323,6 +1323,19 @@ static unsigned int sbp2_status_to_sense
 	}
 }
 
+static void sbp2_unmap_scatterlist(struct device *card_device,
+				   struct sbp2_command_orb *orb)
+{
+	if (scsi_sg_count(orb->cmd))
+		dma_unmap_sg(card_device, scsi_sglist(orb->cmd),
+			     scsi_sg_count(orb->cmd),
+			     orb->cmd->sc_data_direction);
+
+	if (orb->page_table_bus)
+		dma_unmap_single(card_device, orb->page_table_bus,
+				 sizeof(orb->page_table), DMA_TO_DEVICE);
+}
+
 static void complete_command_orb(struct sbp2_orb *base_orb,
 				 struct sbp2_status *status)
 {
@@ -1364,15 +1377,7 @@ static void complete_command_orb(struct 
 
 	dma_unmap_single(device->card->device, orb->base.request_bus,
 			 sizeof(orb->request), DMA_TO_DEVICE);
-
-	if (scsi_sg_count(orb->cmd) > 0)
-		dma_unmap_sg(device->card->device, scsi_sglist(orb->cmd),
-			     scsi_sg_count(orb->cmd),
-			     orb->cmd->sc_data_direction);
-
-	if (orb->page_table_bus != 0)
-		dma_unmap_single(device->card->device, orb->page_table_bus,
-				 sizeof(orb->page_table), DMA_TO_DEVICE);
+	sbp2_unmap_scatterlist(device->card->device, orb);
 
 	orb->cmd->result = result;
 	orb->done(orb->cmd);
@@ -1493,8 +1498,10 @@ static int sbp2_scsi_queuecommand(struct
 	orb->base.request_bus =
 		dma_map_single(device->card->device, &orb->request,
 			       sizeof(orb->request), DMA_TO_DEVICE);
-	if (dma_mapping_error(device->card->device, orb->base.request_bus))
+	if (dma_mapping_error(device->card->device, orb->base.request_bus)) {
+		sbp2_unmap_scatterlist(device->card->device, orb);
 		goto out;
+	}
 
 	sbp2_send_orb(&orb->base, lu, lu->tgt->node_id, generation,
 		      lu->command_block_agent_address + SBP2_ORB_POINTER);


-- 
Stefan Richter
-=====-==--= ---= ==-==
http://arcgraph.de/sr/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/