At Mon, 8 Aug 2005 23:05:24 +0200,
Adrian Bunk wrote:
>
> On Mon, Aug 08, 2005 at 12:11:21PM +0200, Takashi Iwai wrote:
> > At Sat, 6 Aug 2005 17:09:40 +0200,
> > Adrian Bunk wrote:
> > >
> > >
> > > Looking at how few is left from kcalloc, can't we make it a
> > > "static inline" function in sl
On Mon, Aug 08, 2005 at 12:11:21PM +0200, Takashi Iwai wrote:
> At Sat, 6 Aug 2005 17:09:40 +0200,
> Adrian Bunk wrote:
> >
> >
> > Looking at how few is left from kcalloc, can't we make it a
> > "static inline" function in slab.h?
> >
> > This would optimize nicely for all of the users where th
At Sat, 6 Aug 2005 17:09:40 +0200,
Adrian Bunk wrote:
>
> On Fri, Aug 05, 2005 at 09:52:32AM +0300, Pekka J Enberg wrote:
> >...
> > --- 2.6.orig/mm/slab.c
> > +++ 2.6/mm/slab.c
> > @@ -2555,6 +2555,20 @@ void kmem_cache_free(kmem_cache_t *cache
> > EXPORT_SYMBOL(kmem_cache_free);
> >
> > /**
>What prevents a rogue user to call this function a number of times to
>waste resources?
Sorry to jump in, but wasting resources is a different matter than
overwriting kernel memory.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Fri, Aug 05, 2005 at 09:52:32AM +0300, Pekka J Enberg wrote:
>...
> --- 2.6.orig/mm/slab.c
> +++ 2.6/mm/slab.c
> @@ -2555,6 +2555,20 @@ void kmem_cache_free(kmem_cache_t *cache
> EXPORT_SYMBOL(kmem_cache_free);
>
> /**
> + * kzalloc - allocate memory. The memory is set to zero.
> + * @size:
On Sat, 2005-08-06 at 02:40 +0200, Roman Zippel wrote:
> I actually looked at the current kcalloc users and besides a few unchecked
> module parameters, the arguments were either constant or had to be checked
> anyway. I didn't find a single example which required the "safety" of
> kcalloc().
E
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> Maybe it helps if I give the basic bug scenario first (pseudo C)
>
> void some_ioctl_func(...)
> {
> int count, i;
> struct foo *ptr;
>
> copy_from_user(&count,...);
>
> ptr = kmalloc(sizeof(struct foo) * count);
>
> if (!ptr)
>
On 8/5/05, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Hmm. If we had kcmalloc then we may be able to add a zero bit to the slab
> allocator. If we would obtain zeroed pages for the slab then we may skip
> zeroing of individual entries. However, the cache warming effect of the
> current zeroing
On Fri, 5 Aug 2005, Stephen Pollei wrote:
> > On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > > > This would imply a similiar kmalloc() would be useful as well.
> > > > Second, how relevant is it for the kernel?
> > > we've had a non-negliable amount of security holes because of this
> > So why do
On 8/5/05, Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > > This would imply a similiar kmalloc() would be useful as well.
> > > Second, how relevant is it for the kernel?
> > we've had a non-negliable amount of security holes because of this
> So why do
On Fri, 2005-08-05 at 12:56 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
>
> > > > we've had a non-negliable amount of security holes because of this
> > >
> > > So why don't we have a similiar kmalloc()?
> >
> > nope kmalloc is not an array allocator
> >
>
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > > we've had a non-negliable amount of security holes because of this
> >
> > So why don't we have a similiar kmalloc()?
>
> nope kmalloc is not an array allocator
>
> > > it makes it easy and safe. Of course you can and should check it in all
On Fri, 2005-08-05 at 12:32 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
>
> > > This would imply a similiar kmalloc() would be useful as well.
> > > Second, how relevant is it for the kernel?
> >
> > we've had a non-negliable amount of security holes because
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > This would imply a similiar kmalloc() would be useful as well.
> > Second, how relevant is it for the kernel?
>
> we've had a non-negliable amount of security holes because of this
So why don't we have a similiar kmalloc()?
> > Is that reall
On Fri, 2005-08-05 at 12:07 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
>
> > kcalloc does have value, in that it's a nice api to avoid multiplication
> > overflows. Just for "1" it's indeed not the most useful API.
>
> This would imply a similiar kmalloc()
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> kcalloc does have value, in that it's a nice api to avoid multiplication
> overflows. Just for "1" it's indeed not the most useful API.
This would imply a similiar kmalloc() would be useful as well.
Second, how relevant is it for the kernel? Is
On Fri, 2005-08-05 at 11:37 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 4 Aug 2005, Andrew Morton wrote:
>
> > > +static inline void *kzalloc(size_t size, unsigned int __nocast flags)
> > > +{
> > > + return kcalloc(1, size, flags);
> > > +}
> > > +
> >
> > That'll generate just as much code as
Hi,
On Thu, 4 Aug 2005, Andrew Morton wrote:
> > +static inline void *kzalloc(size_t size, unsigned int __nocast flags)
> > +{
> > + return kcalloc(1, size, flags);
> > +}
> > +
>
> That'll generate just as much code as simply using kcalloc(1, ...). This
> function should be out-of-line and E
On Thu, 4 Aug 2005, Andrew Morton wrote:
> That'll generate just as much code as simply using kcalloc(1, ...). This
> function should be out-of-line and EXPORT_SYMBOL()ed. And kcalloc() can
> call it too..
Yes, much better now. Thanks Andrew.
Pekka
[PATCH] intro
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
>
> [PATCH] use kzalloc instead of kmalloc/memset
>
dammit, I was hoping for akpmalloc()
>
> +static inline void *kzalloc(size_t size, unsigned int __nocast flags)
> +{
> + return kcalloc(1, size, flags);
> +}
> +
That'll generate just as much cod
Hi Andrew,
Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > This patch converts kernel/ to use kcalloc instead of kmalloc/memset.
On Thu, 4 Aug 2005, Andrew Morton wrote:
> grr.
I am learning grep. Please don't eat me!
> > - struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
> > + struct
Pekka Enberg <[EMAIL PROTECTED]> wrote:
>
> This patch converts kernel/ to use kcalloc instead of kmalloc/memset.
>
grr.
> -struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
> +struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL);
Notice how every conversion you did pas
This patch converts kernel/ to use kcalloc instead of kmalloc/memset.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
intermodule.c |3 +--
params.c |4 ++--
power/pm.c|3 +--
resource.c|3 +--
workqueue.c |3 +--
5 files changed, 6 insertions(+), 10 deleti
23 matches
Mail list logo
