linux-kernel - Re: [PATCH] ipc/mqueue: use correct gfp flags in msg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20120514165401.e4efc2fd.akpm@linux-foundation.org>
Date:	Mon, 14 May 2012 16:54:01 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Sasha Levin <levinsasha928@...il.com>
Cc:	dledford@...hat.com, kosaki.motohiro@...fujitsu.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipc/mqueue: use correct gfp flags in msg_insert

On Mon, 14 May 2012 23:05:25 +0200
Sasha Levin <levinsasha928@...il.com> wrote:

> msg_insert() tries to allocate using GFP_KERNEL, while in both cases when it's called,
> it's coming from an atomic context. Introduced by 7dd7edf ("ipc/mqueue: improve
> performance of send/recv").
> 
> Use GFP_ATOMIC instead.
> 
> Also, fix up coding style in the kzalloc while we're there.
> 
> Signed-off-by: Sasha Levin <levinsasha928@...il.com>
> ---
>  ipc/mqueue.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 30f6f8f..9ec6896 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -133,7 +133,7 @@ static int msg_insert(struct msg_msg *msg, struct mqueue_inode_info *info)
>  		else
>  			p = &(*p)->rb_right;
>  	}
> -	leaf = kzalloc(sizeof(struct posix_msg_tree_node), GFP_KERNEL);
> +	leaf = kzalloc(sizeof(*leaf), GFP_ATOMIC);
>  	if (!leaf)
>  		return -ENOMEM;
>  	rb_init_node(&leaf->rb_node);

hm, that should have spewed warnings everywhere the first time anyone
tested it.  Doug, is a re-read of Documentation/SubmitChecklist needed?

Switching to GFP_ATOMIC is a bit regrettable.  Can we avoid this by
speculatively allocating the memory before taking the lock, then free
it again if we ended up not using it?
--
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/