On 5/8/07, Randy Dunlap <[email protected]> wrote:
On Tue, 8 May 2007 11:57:07 -0400 (EDT) Alan Stern wrote:
> On Tue, 8 May 2007, Greg KH wrote:
>
> > > The problem was in drivers/usb/core/config.c in function
> > > usb_parse_interface:
> > > ---
> > > num_ep = num_ep_orig = alt->desc.bNumEndpoints;
> > > ...
> > > len = sizeof(struct usb_host_endpoint) * num_ep;
> > > alt->endpoint = kzalloc(len, GFP_KERNEL);
> > > ---
> > >
> > > num_ep can be 0, as it was in my case, so following patch makes this
> > > situation more obvious
> > > and clear.
>
> How about instead just doing:
>
> + num_ep = max(num_ep, 1);
> len = sizeof(struct usb_host_endpoint) * num_ep;
>
> Also, wasn't it true at one point that it was legal to call kmalloc() with
> a length of 0? ISTR seeing somewhere that it's true for regular malloc().
kmalloc(0) was legal with CONFIG_SLAB=y. However, there is now
something called SLUB, which just returned an error when size == 0.
SLUB works correctly with kmalloc(0) too, but it calls
WARN_ON_ONCE(size == 0);
in include/linux/slub_def.h: kmalloc_index.
btw: as I know when kmalloc(0) both slub and slab allocate the
smallest possible size. Can this size be smaller than sizeof(struct
usb_host_endpoint)? If it is, may it be a problem?
thanks.
Dan Kruchinin.
It has recently been modified to mirror the SLAB behavior but also
do a stack dump so that "bad" callers can be fixed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
