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]
Date:	Mon, 6 Jun 2011 10:14:10 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	shawn.guo@...aro.org, patches@...aro.org, vinod.koul@...el.com,
	gregkh@...e.de, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, dan.j.williams@...el.com,
	cjb@...top.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/3] dmaengine: add new dma API for
	max_segment_number

On Mon, Jun 06, 2011 at 05:06:03PM +0900, FUJITA Tomonori wrote:
> max_segs isn't unrelated with the dma mapping API. I explained above,
> IOMMUs doesn't increase the number of segments (could decrease the
> number of segments by merging).
> 
> The limitation about the number of segment already lives elsewhere
> (e.g. queue's limits.max_segments).

I think you're missing the point entirely.

Lets take the problem at hand: you have two devices.  One of them is
handled by the DMA engine code.  One of them is a block device.

The block layer needs to know the various parameters of what is
allowable for DMA, including such things as the maximum size of a
segment, and the _number_ of segments that can be placed into any
one request.

As the DMA provider is _entirely_ separate and unknown to the block
device driver, the block device driver has no way to sanely provide
these parameters to the block layer - they are not a property of the
block device driver, but of the DMA provider.

However, the DMA provider can't know that it'll be interacting with
the block layer, so there's no way for the DMA provider to tell the
block layer about its parameters.

The only way this can happen is for there to be some way for the DMA
provider to export this information to the block device driver, so
the block device driver can then inform its upper layers what the DMA
capabilities are.

So to say that "it lives elsewhere" is completely missing the problem
trying to be addressed by these patches.
--
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