On Mon, Jan 06, 2014 at 09:26:20AM +0000, David Laight wrote: > > From: David Cohen > > On Fri, Dec 20, 2013 at 09:26:35AM -0000, David Laight wrote: > > > > From: David Cohen > > > The effect of this change is really to remove the first allocation and > > > add 8 bytes (or maybe a pointer) to the start of the second one. > > > So it is extremely unlikely to fail when the old code would work. > > > > Currently struct urb_priv has a dynamic array of pointers to struct > > xhci_td. You're replacing the pointer by structs itself. Now, instead of > > 2 kmallocs() (1 for urb_priv and another for size * xhci_td) we've 1 > > kmalloc() with urb_priv + size * xhci_td. > > You misread the old code. > The first malloc was for the header and 'n' pointers. > The second malloc was for 'n' copies of the structure. That's exactly what I described but in a more complicated way :) The new kmalloc is going to be "n * sizeof(struct) - n * sizeof(pointer)" bigger. I don't know what is the usual range of values for "n", but my experience with android devices with non-abundant memory size is that they are sensible to kmalloc > PAGE_SIZE. Back to your patch description, you mention new kmalloc size may be PAGE_SIZE + 8 bytes, which means kmalloc may have to find 2 consecutive free pages. Of course it is not a big issue, but I don't see a reason to unnecessarily change 2 kmalloc < PAGE_SIZE by one possibly > PAGE_SIZE. Br, David Cohen > > David > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
