All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Epler <jepler@unpythonic.net>
To: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
	Joe Perches <joe@perches.com>, Hannes Reinecke <hare@suse.de>,
	"JBottomley@parallels.com" <JBottomley@parallels.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: kcalloc/kmalloc_array could BUILD_BUG_ON for too-big constant arguments (was Re: [PATCH] [RESEND] aic7xxx: replace kmalloc/memset by kzalloc)
Date: Fri, 27 Mar 2015 14:48:24 -0500	[thread overview]
Message-ID: <20150327194824.GC88629@unpythonic.net> (raw)
In-Reply-To: <5514A679.5030005@free-electrons.com>

The following is a sketch of how a macro kcalloc could BUILD_BUG_ON for
overflows of two compile-time operands, or call "kcalloc_variable" for
nonconstant arguments.  Tested on gcc 4.7.2 only, since it's what I had to
hand.  I didn't do any testing beyond checking that fn2 didn't build, and that
fn1/3 had plausible-looking code on x86_64.

typedef unsigned long size_t;
#define SIZE_MAX (~(size_t)0)
typedef int gfp_t;
extern void *kzalloc(size_t n, gfp_t flags);
extern void *kcalloc_variable(size_t n, size_t size, gfp_t flags);
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))

#define kcalloc(n, size, flags) \
	__builtin_choose_expr(__builtin_constant_p((n) | (size)), \
		( \
			BUILD_BUG_ON((n) > SIZE_MAX / (size)), \
			kzalloc((n) * (size), (flags)) \
		), kcalloc_variable((n), (size), (flags)))


void fn1() { kcalloc(3, 3, 0); }
//void fn2() { kcalloc(2, ~(size_t)0, 0); }// compile-time BUILD_BUG_ON
void fn3(int i) { kcalloc(2, i, 0); }

Jeff

      parent reply	other threads:[~2015-03-27 19:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-16 19:14 [PATCH] aic7xxx: replace kmalloc/memset by kzalloc Michael Opdenacker
2014-10-16 19:28 ` Joe Perches
2014-10-16 19:30   ` Michael Opdenacker
2014-10-16 20:05     ` Elliott, Robert (Server Storage)
2015-03-22 16:31       ` [PATCH] [RESEND] " Michael Opdenacker
2015-03-23  6:59         ` Hannes Reinecke
2015-03-24 20:46           ` Michael Opdenacker
2015-03-24 20:57             ` Joe Perches
2015-03-24 23:16               ` Elliott, Robert (Server Storage)
2015-03-27  0:38                 ` Michael Opdenacker
2015-03-27  0:51                   ` Michael Opdenacker
2015-03-27 19:48                   ` Jeff Epler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150327194824.GC88629@unpythonic.net \
    --to=jepler@unpythonic.net \
    --cc=Elliott@hp.com \
    --cc=JBottomley@parallels.com \
    --cc=hare@suse.de \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michael.opdenacker@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.