search for: kmalloc

Hi, I''ve discovered that some btrfs code doesn''t check whether kmalloc() call succeeded. I poorly understand what this code does and how it can be changed, maybe it would be happy with __GFP_NOFAIL. Also there are BUG_ON() after kmalloc()''s, if they could be changed not to panic it would be great. --- ./fs/btrfs/compression.c 2010-07-06 16:45:48.000000000...

Correct ugly oversight, we need to check the return values of kmalloc and vmbus_recvpacket and return if they fail. I also tightened up the call to kmalloc. Thanks to Evgeniy Polyakov <zbr at ioremap.net> for pointing this out. Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> ---...

Correct ugly oversight, we need to check the return values of kmalloc and vmbus_recvpacket and return if they fail. I also tightened up the call to kmalloc. Thanks to Evgeniy Polyakov <zbr at ioremap.net> for pointing this out. Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> ---...

Correct issue with not checking kmalloc return value. This fix now only uses one receive buffer for all hv_utils channels, and will do only one kmalloc on init and will return with a -ENOMEM if kmalloc fails on initialize. Thanks to Evgeniy Polyakov <zbr at ioremap.net> for pointing this out. And thanks to Jesper Juhl <jj at c...

Correct issue with not checking kmalloc return value. This fix now only uses one receive buffer for all hv_utils channels, and will do only one kmalloc on init and will return with a -ENOMEM if kmalloc fails on initialize. Thanks to Evgeniy Polyakov <zbr at ioremap.net> for pointing this out. And thanks to Jesper Juhl <jj at c...

...oc_pages_nodemask+0x7aa/0x9d0 [54807.480510] [<ffffffff810ed069>] ? trace_hardirqs_off_caller+0xb9/0x160 [54807.495622] [<ffffffff81175277>] alloc_pages_current+0xb7/0x180 [54807.510530] [<ffffffff81138059>] __get_free_pages+0x9/0x40 [54807.525185] [<ffffffff8117cbdc>] __kmalloc+0x19c/0x1c0 [54807.539538] [<ffffffff8190e9b4>] alloc_netdev_mqs+0x64/0x340 [54807.553814] [<ffffffff8192ac20>] ? alloc_etherdev_mqs+0x20/0x20 [54807.567777] [<ffffffff816dc3e4>] xenvif_alloc+0x64/0x2c0 [54807.581473] [<ffffffff816dbc57>] netback_probe+0x287/0x2d0 [54807...

On Tue, Apr 24, 2018 at 08:29:14AM -0400, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Matthew Wilcox wrote: > > > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > > Some bugs (such as buffer overflows) are better detected > > > with kmalloc code, so we must test the kmalloc path too. > > > > Well now, this brings up another item for the collective TODO list -- > > implement redzone checks for vmalloc. Unless this is something already > > taken care of by kasan or similar. > > The kmalloc overflow testi...

On Tue, Apr 24, 2018 at 08:29:14AM -0400, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Matthew Wilcox wrote: > > > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > > Some bugs (such as buffer overflows) are better detected > > > with kmalloc code, so we must test the kmalloc path too. > > > > Well now, this brings up another item for the collective TODO list -- > > implement redzone checks for vmalloc. Unless this is something already > > taken care of by kasan or similar. > > The kmalloc overflow testi...

Correct issue with not checking kmalloc return value. This fix now only uses one receive buffer for all hv_utils channels, and will do only one kmalloc on init and will return with a -ENOMEM if kmalloc fails on initialize. And properly clean up memory on failure. Thanks to Evgeniy Polyakov <zbr at ioremap.net> for pointing this...

Correct issue with not checking kmalloc return value. This fix now only uses one receive buffer for all hv_utils channels, and will do only one kmalloc on init and will return with a -ENOMEM if kmalloc fails on initialize. And properly clean up memory on failure. Thanks to Evgeniy Polyakov <zbr at ioremap.net> for pointing this...

Replaced calls to kmalloc followd by memcpy with a single call to kmemdup. This patch was found using coccicheck. Signed-off-by: Alexandru Gheorghiu <gheorghiuandru at gmail.com> --- fs/ocfs2/localalloc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/lo...

Starting with 3.7 rc1, my workstation seems to loose ram. Up until (and including) 3.6, used-(buffers+cached) was roughly the same as sum(rss) (taking shared into account). Now there is an approx 6G gap. When the box first starts, it is clearly less swappy than with <= 3.6; I can''t tell whether that is related. The reduced swappiness persists. It seems to get worse when I update

...guidelines") suggests never naming goto labels after the goto location - that is the error that is handled. But it's actually pretty common and IMHO it's a reasonable style provided each error gets its own label, and each label comes after the matching cleanup: foo = kmalloc(SIZE, GFP_KERNEL); if (!foo) goto err_foo; foo->bar = kmalloc(SIZE, GFP_KERNEL); if (!foo->bar) goto err_bar; ... kfree(foo->bar); err_bar:...

...guidelines") suggests never naming goto labels after the goto location - that is the error that is handled. But it's actually pretty common and IMHO it's a reasonable style provided each error gets its own label, and each label comes after the matching cleanup: foo = kmalloc(SIZE, GFP_KERNEL); if (!foo) goto err_foo; foo->bar = kmalloc(SIZE, GFP_KERNEL); if (!foo->bar) goto err_bar; ... kfree(foo->bar); err_bar:...

On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > Some bugs (such as buffer overflows) are better detected > with kmalloc code, so we must test the kmalloc path too. Well now, this brings up another item for the collective TODO list -- implement redzone checks for vmalloc. Unless this is something already taken care of by kasan or similar.

On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > Some bugs (such as buffer overflows) are better detected > with kmalloc code, so we must test the kmalloc path too. Well now, this brings up another item for the collective TODO list -- implement redzone checks for vmalloc. Unless this is something already taken care of by kasan or similar.

The size of de/compress buffer and LZO1X_MEM_COMPRESS is small enough. Allocating it with kmalloc rather than vmalloc is preferred. This patch depends on my previous patch, “btrfs: fix decompress buffer size”. Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com> Cc: David Sterba <dsterba@suse.cz> --- fs/btrfs/lzo.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-...

...short num_vqs; > > struct virtio_device *vdev = vblk->vdev; > > > > @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk) > > num_vqs = 1; > > > > ...just do > > err = -ENOMEM; > > here and... > > > vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL); > > - if (!vblk->vqs) { > > - err = -ENOMEM; > > - goto out; > > - } > > + if (!vblk->vqs) > > + return -ENOMEM; > > > > names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL); > > - if (!...

...short num_vqs; > > struct virtio_device *vdev = vblk->vdev; > > > > @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk) > > num_vqs = 1; > > > > ...just do > > err = -ENOMEM; > > here and... > > > vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL); > > - if (!vblk->vqs) { > > - err = -ENOMEM; > > - goto out; > > - } > > + if (!vblk->vqs) > > + return -ENOMEM; > > > > names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL); > > - if (!...

ext2 & ext3 lists, Attatched is a patch that allows ext2 and ext3 to link correctly when the kernel is configured with a large NR_CPUS. We do have an immediate need for this patch. Any opinions on this? The per-cpu lists are causing the kmalloc to fail due to allocating more than the max. thanks mh -- Martin Hicks Wild Open Source Inc. mort@wildopensource.com 613-266-2296 # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch...