From: Satoru Takeuchi <satoru.takeuchi@gmail.com>
To: dm-devel@redhat.com
Cc: ejt@redhat.com, ruby.wktk@gmail.com
Subject: [BUG] dm-writeboost: too big nr_rambuf_pool causes massive memory pressure or panic.
Date: Sat, 12 Jul 2014 18:06:58 +0900 [thread overview]
Message-ID: <87egxr0wul.wl%satoru.takeuchi@gmail.com> (raw)
Hi,
Since the upper limit of nr_rambuf_pool argument, user can set too big value
to this argument.
drivers/md/dm-writeboost-target.c:
===============================================================================
static int consume_optional_argv(struct wb_device *wb, struct dm_arg_set *as)
{
int r = 0;
struct dm_target *ti = wb->ti;
static struct dm_arg _args[] = {
{0, 4, "Invalid optional argc"},
{4, 10, "Invalid segment_size_order"},
{1, UINT_MAX, "Invalid nr_rambuf_pool"},
};
===============================================================================
It can cause the massive memory pressure to kernel by user's mistake
and results in
- ENOMEM at the (1) or somewhere, and
- panic at (2).
drivers/md/dm-writeboost-metadata.c:
===============================================================================
...
static int init_rambuf_pool(struct wb_device *wb)
{
int r = 0;
size_t i;
wb->rambuf_pool = kmalloc(sizeof(struct rambuffer) * wb->nr_rambuf_pool,
GFP_KERNEL);
if (!wb->rambuf_pool)
return -ENOMEM; # ................. (1)
wb->rambuf_cachep = kmem_cache_create("dmwb_rambuf",
1 << (wb->segment_size_order + SECTOR_SHIFT),
1 << (wb->segment_size_order + SECTOR_SHIFT),
SLAB_RED_ZONE, NULL);
if (!wb->rambuf_cachep) {
r = -ENOMEM;
goto bad_cachep;
}
for (i = 0; i < wb->nr_rambuf_pool; i++) {
size_t j;
struct rambuffer *rambuf = wb->rambuf_pool + i;
rambuf->data = kmem_cache_alloc(wb->rambuf_cachep, GFP_KERNEL);
if (!rambuf->data) {
WBERR("Failed to allocate rambuf->data");
for (j = 0; j < i; j++) {
rambuf = wb->rambuf_pool + j;
kmem_cache_free(wb->rambuf_cachep, rambuf->data);
}
r = -ENOMEM;
goto bad_alloc_data;
}
check_buffer_alignment(rambuf->data);
}
return r;
bad_alloc_data:
kmem_cache_destroy(wb->rambuf_cachep);
bad_cachep:
kfree(wb->rambuf_pool);
BUG(); # ........(2)
return r;
}
...
===============================================================================
Please decide the appropriate upper limit of nr_rambuf_pool (unfortunately
I don't know about it), and remove BUG() at (2) if it's unnecessary.
Thanks,
Satoru
next reply other threads:[~2014-07-12 9:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-12 9:06 Satoru Takeuchi [this message]
2014-07-18 1:01 ` [BUG] dm-writeboost: too big nr_rambuf_pool causes massive memory pressure or panic Akira Hayakawa
2014-07-19 2:13 ` Satoru Takeuchi
2014-07-19 11:40 ` [PATCH] dm-writeboost: Remove unsure BUG() from init_rambuf_pool Satoru Takeuchi
2014-07-19 18:13 ` Alasdair G Kergon
2014-07-21 13:52 ` Satoru Takeuchi
2014-07-22 7:14 ` Akira Hayakawa
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=87egxr0wul.wl%satoru.takeuchi@gmail.com \
--to=satoru.takeuchi@gmail.com \
--cc=dm-devel@redhat.com \
--cc=ejt@redhat.com \
--cc=ruby.wktk@gmail.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.