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:	Wed, 17 Feb 2010 20:26:26 -0800
From:	Greg KH <greg@...ah.com>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Linux-usb <linux-usb@...r.kernel.org>,
	Linux USB <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [PATCH 2.6.34] ehci-hcd: add option to enable 64-bit DMA
	support

On Wed, Feb 17, 2010 at 09:10:13PM -0600, Robert Hancock wrote:
> Add a module parameter to allow the user to enable 64-bit DMA support in EHCI,
> which has been forcibly disabled since 2003 - see:
> 
> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg17230.html
> 
> At that time the comment was "it'd only matter on a few big Intel boxes anyway",
> however the situation is much different today when many new machines have 4GB
> or more of RAM and IOMMU/SWIOTLB are thus needlessly required for USB transfers.
> For now, the support remains disabled by default and is controlled by an
> allow_64bit module parameter.
> 
> Note that some USB device drivers may require updates to pass the DMA
> capabilities up to their higher layers to avoid unnecessary IOMMU or bounce-
> buffer use (i.e. networking layer NETIF_F_HIGHDMA). Some of these checks were
> disabled by the patch listed above, and more may be required again today.
> However, those previous checks were done incorrectly using dma_supported,
> which checks to see whether a device's DMA mask can be validly set to a given
> mask, not whether its previously set mask will accomodate the mask passed in.
> 
> Signed-off-by: Robert Hancock <hancockrwd@...il.com>

What is the "advantage" that setting this option would allow people to
do that the code currently does not?  Is such an advantage measurable at
the slow rates that the EHCI driver controls?

Is there any way to dynamically figure out if we can enable this or not?
Adding module paramaters sucks, as they are hard to configure for most
users, and they tend to be ignored.

And are you really ok with enabling this on a system-wide level, and not
on a per-controller level?  Does that work properly on all systems?

And if the system does not support it, and a user enables it, who is
going to support their broken system?  :)

thanks,

greg k-h
--
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