search for: kmallocs

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 +0400 +++

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> --- drivers/staging/hv/hv_utils.c |

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> --- drivers/staging/hv/hv_utils.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 chaosbits.net> and Ky Srinivasan <ksrinivasan at

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 chaosbits.net> and Ky Srinivasan <ksrinivasan at

Hi Wei, I ran into the following problem when trying to boot another guest after less than a day of uptime. (the system started 15 guests at boot already which went fine). dom0 is allocated a fixed 1536M. Both host as pv guests run the same kernel, some hvm''s run a slightly older kernel (3.9 f.e.) The are quite some granttable messages in xl dmesg, i also included these and a

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

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

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 out. And thanks to Jesper Juhl <jj at chaosbits.net>

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 out. And thanks to Jesper Juhl <jj at chaosbits.net>

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/localalloc.c index aebeacd..839183f 100644 --- a/fs/ocfs2/localalloc.c +++

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

commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle: add some more error handling 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

commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle: add some more error handling 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

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(-)

On 07/18/16 at 05:21P, Cornelia Huck wrote: > On Mon, 18 Jul 2016 22:01:29 +0800 > Minfei Huang <mnfhuang at gmail.com> wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 42758b5..d920512 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -381,9 +381,9 @@ static int init_vq(struct

On 07/18/16 at 05:21P, Cornelia Huck wrote: > On Mon, 18 Jul 2016 22:01:29 +0800 > Minfei Huang <mnfhuang at gmail.com> wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 42758b5..d920512 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -381,9 +381,9 @@ static int init_vq(struct

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