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, 14 Apr 2010 10:08:47 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Pedro Ribeiro <pedrib@...il.com>
cc:	linux-usb@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, <alsa-devel@...a-project.org>
Subject: Re: USB transfer_buffer allocations on 64bit systems

On Wed, 14 Apr 2010, Pedro Ribeiro wrote:

> On 14 April 2010 11:09, Daniel Mack <daniel@...aq.de> wrote:
> 
> > Thanks! So the only thing I can do for now is submit exactly this patch.
> > At least, it helps you and it shouldn't break anything. The question
> > remains whether this type of memory should be used for all
> > transfer_buffers.
> >
> 
> Is there any chance you could push this to -stable? I don't care
> because I always use the latest kernel, but the next Debian stable and
> Ubuntu LTS are going to use 2.6.32.

No!  Please don't do it: Don't submit the patch and _certainly_ don't
submit it to -stable.  It doesn't fix anything; it only works around a
bug, and at the moment we don't even know if the bug is in the kernel
or in Pedro's hardware (and even though it affects two different
systems of his, nobody else has reported a similar problem).  Papering
over it will only remove the incentive to fix it properly.

In addition, you'll most likely find that lots of Linux developers will
object vociferously to any proposed patch that uses GFP_DMA.  That flag
is supposed to be _only_ for ISA devices, which really need it.  By 
limiting the memory allocation to the lowest 16 MB of physical memory, 
it greatly increases the chances that the allocation will fail.

Alan Stern

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