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] [day] [month] [year] [list]
Message-ID: <52264FD4.1090809@linux.vnet.ibm.com>
Date:	Tue, 03 Sep 2013 16:08:36 -0500
From:	Brian King <brking@...ux.vnet.ibm.com>
To:	"Philip J. Kelleher" <pjk1939@...ux.vnet.ibm.com>
CC:	axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] rsxx: Moving pci_map_page to prevent overflow

On 08/27/2013 05:59 PM, Philip J. Kelleher wrote:
> diff -uprN -X linux-block-vanilla/Documentation/dontdiff linux-block-vanilla/drivers/block/rsxx/dma.c linux-block/drivers/block/rsxx/dma.c
> --- linux-block-vanilla/drivers/block/rsxx/dma.c	2013-08-12 15:22:18.612863489 -0500
> +++ linux-block/drivers/block/rsxx/dma.c	2013-08-12 15:23:22.158858765 -0500
> @@ -433,6 +434,27 @@ static void rsxx_issue_dmas(struct rsxx_
>  			continue;
>  		}
> 
> +		if (dma->cmd == HW_CMD_BLK_WRITE)
> +			dir = PCI_DMA_TODEVICE;
> +		else
> +			dir = PCI_DMA_FROMDEVICE;
> +
> +		/*
> +		 * The function pci_map_page is placed here because we can
> +		 * only, by design, issue up to 255 commands to the hardware
> +		 * at one time per DMA channel. So the maximum amount of mapped
> +		 * memory would be 255 * 4 channels * 4096 Bytes which is less
> +		 * than 2GB, the limit of a x8 Non-HWWD PCIe slot. This way the
> +		 * pci_map_page function should never fail because of a
> +		 * lack of mappable memory.
> +		 */
> +		dma->dma_addr = pci_map_page(ctrl->card->dev, dma->page,
> +				     dma->pg_off, dma->sub_page.cnt << 9, dir);
> +		if (pci_dma_mapping_error(ctrl->card->dev, dma->dma_addr)) {

Do you also need to do a push_tracker here as well so you don't leak a tag?
Why is this error case handled different compared to the dma_fault case earlier
in this same function?

> +			kmem_cache_free(rsxx_dma_pool, dma);
> +			return;
> +		}
> +
>  		set_tracker_dma(ctrl->trackers, tag, dma);
>  		hw_cmd_buf[ctrl->cmd.idx].command  = dma->cmd;
>  		hw_cmd_buf[ctrl->cmd.idx].tag      = tag;

-Brian

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ