A number of size_t's is what we want to allocate memory for, not a
number of size_t pointers (at least as far as I can tell).
Now, depending on platform, sizeof(size_t *) may be >= sizeof(size_t)
so things actually work, but that's not really a portable assumption,
so let's use the value we actually mean.
Signed-off-by: Jesper Juhl <j...@chaosbits.net>
---
kernel/relay.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/relay.c b/kernel/relay.c
index e8cd202..806931b 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -166,13 +166,13 @@ static struct rchan_buf *relay_create_buf(struct rchan
*chan)
{
struct rchan_buf *buf;
- if (chan->n_subbufs > UINT_MAX / sizeof(size_t *))
+ if (chan->n_subbufs > UINT_MAX / sizeof(size_t))
return NULL;
buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);
if (!buf)
return NULL;
- buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t *), GFP_KERNEL);
+ buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t), GFP_KERNEL);
if (!buf->padding)
goto free_buf;
--
1.7.1
--
Jesper Juhl <j...@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
