Re: [linux-usb-devel] [PATCH -mm] drivers/usb/core/config.c: kzalloc(0, ..)

["Dan Kruchinin" <dubalom@gmail.com>]

On 5/8/07, Randy Dunlap <rdunlap@xenotime.net> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/