[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070508094502.efc32182.rdunlap@xenotime.net>
Date: Tue, 8 May 2007 09:45:02 -0700
From: Randy Dunlap <rdunlap@...otime.net>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Dan Kruchinin <dubalom@...il.com>, Greg KH <greg@...ah.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] [PATCH -mm] drivers/usb/core/config.c:
kzalloc(0, ..)
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.
It has recently been modified to mirror the SLAB behavior but also
do a stack dump so that "bad" callers can be fixed.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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