* mmotm 2008-12-09-15-24: memory corruption (bio slab)
@ 2008-12-10 13:57 Jiri Slaby
2008-12-10 14:11 ` Jens Axboe
0 siblings, 1 reply; 4+ messages in thread
From: Jiri Slaby @ 2008-12-10 13:57 UTC (permalink / raw)
To: Jens Axboe; +Cc: akpm, linux-kernel, viro, linux-fsdevel, Jiri Slaby
Hi,
on every bootup of this kernel, I get this (not sure if it is right after the moment when / gets mounted from md1):
wlan0 renamed to wlan1
udev: renamed network interface wlan0 to wlan1
swap_cgroup: uses 7848 bytes of vmalloc for pointer array space and 4018176 bytes to hold mem_cgroup pointers on swap
swap_cgroup can be disabled by noswapaccount boot option.
Adding 2008084k swap on /dev/sdb6. Priority:-1 extents:1 across:2008084k
EXT3 FS on md1, internal journal
bio: create slab <bio-1> at 1
=============================================================================
BUG bio-1: Redzone overwritten
-----------------------------------------------------------------------------
INFO: 0xffff88007bacf068-0xffff88007bacf06f. First byte 0x68 instead of 0xcc
INFO: Allocated in 0x6b6b6b6b6b6b6b6b age=10706345584330245030 cpu=1802201963 pid=1802201963
INFO: Freed in 0x6b6b6b6b6b6b6b6b age=6527005130130424742 cpu=1802201963 pid=1802201963
INFO: Slab 0xffffe20001b0dd48 objects=21 used=4 fp=0xffff88007bacf300 flags=0x40000000000000c3
INFO: Object 0xffff88007bacf000 @offset=0 fp=0x0000000000001000
Object 0xffff88007bacf000: fd 6f 57 04 00 00 00 00 00 00 00 00 00 00 00 00 375oW.............
Object 0xffff88007bacf010: 80 86 c2 7c 00 88 ff ff 19 00 00 00 00 00 00 00 ..302|..377377........
Object 0xffff88007bacf020: 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 ................
Object 0xffff88007bacf030: 00 00 00 00 00 10 00 00 00 10 00 00 04 00 00 00 ................
Object 0xffff88007bacf040: ff ff ff ff 00 00 00 00 68 f0 ac 7b 00 88 ff ff 377377377377....h360254{..377377
Object 0xffff88007bacf050: b0 ad 49 80 ff ff ff ff 58 99 b7 7a 00 88 ff ff 260255I.377377377377X.267z..377377
Object 0xffff88007bacf060: 10 98 49 80 ff ff ff ff ..I.377377377377
Redzone 0xffff88007bacf068: 68 1b b1 01 00 e2 ff ff h.261..342377377
Padding 0xffff88007bacf0a8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Padding 0xffff88007bacf0b8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Pid: 815, comm: udevd Tainted: G W 2.6.28-rc7-mm1_64 #490
Call Trace:
<IRQ> [<ffffffff802b6ed6>] print_trailer+0x106/0x160
[<ffffffff802b7145>] check_bytes_and_report+0x125/0x180
[<ffffffff802b83d6>] check_object+0x66/0x280
[<ffffffff802b9e65>] __slab_free+0x225/0x370
[<ffffffff8028f5d2>] ? mempool_free_slab+0x12/0x20
[<ffffffff802bb7f2>] kmem_cache_free+0x72/0xa0
[<ffffffff8028f5d2>] mempool_free_slab+0x12/0x20
[<ffffffff8028f66a>] mempool_free+0x8a/0xa0
[<ffffffff802ea03d>] bio_free+0x4d/0x60
[<ffffffff8049981d>] dm_bio_destructor+0xd/0x10
[<ffffffff802e848b>] bio_put+0x2b/0x40
[<ffffffff8049ae39>] clone_endio+0x89/0xd0
[<ffffffff802e851c>] bio_endio+0x1c/0x40
[<ffffffff8034f42b>] req_bio_endio+0x8b/0xe0
[<ffffffff8034f527>] __end_that_request_first+0xa7/0x2b0
[<ffffffff8034f75c>] end_that_request_data+0x2c/0x70
[<ffffffff8034f80d>] blk_end_io+0x2d/0xb0
[<ffffffff8034f8be>] blk_end_request+0xe/0x10
[<ffffffff80418edb>] scsi_io_completion+0x13b/0x490
[<ffffffff8041250c>] scsi_finish_command+0xac/0xe0
[<ffffffff80418d1a>] scsi_softirq_done+0xba/0x140
[<ffffffff8043df0c>] ? ahci_interrupt+0x9c/0x5c0
[<ffffffff80353a85>] blk_done_softirq+0x75/0x90
[<ffffffff8025ab83>] ? sched_clock_cpu+0x143/0x190
[<ffffffff80244052>] __do_softirq+0xc2/0x190
[<ffffffff8020d6bc>] call_softirq+0x1c/0x30
[<ffffffff8020ea15>] do_softirq+0x45/0x90
[<ffffffff80243d9d>] irq_exit+0x8d/0xa0
[<ffffffff8020ecc5>] do_IRQ+0xc5/0x110
[<ffffffff8020cf93>] ret_from_intr+0x0/0xa
<EOI> <3>FIX bio-1: Restoring 0xffff88007bacf068-0xffff88007bacf06f=0xcc
=============================================================================
BUG bio-1: Redzone overwritten
-----------------------------------------------------------------------------
ffffffff8049981d is in dm_bio_destructor from drivers/md/dm.c.
Inlined vecs doesn't fit to the allocated slab portion in my eyes, doesn't
the patch below make sense?
--
Enlarge bio slabs to include inlined vecs
---
fs/bio.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 40b6488..cd1a439 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -68,7 +68,8 @@ static unsigned int bio_slab_nr, bio_slab_max;
static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
{
- unsigned int sz = sizeof(struct bio) + extra_size;
+ unsigned int sz = sizeof(struct bio) +
+ sizeof(struct bio_vec) * BIO_INLINE_VECS + extra_size;
struct kmem_cache *slab = NULL;
struct bio_slab *bslab;
unsigned int i, entry = -1;
--
1.6.0.5
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: mmotm 2008-12-09-15-24: memory corruption (bio slab) 2008-12-10 13:57 mmotm 2008-12-09-15-24: memory corruption (bio slab) Jiri Slaby @ 2008-12-10 14:11 ` Jens Axboe 2008-12-10 14:30 ` Jens Axboe 0 siblings, 1 reply; 4+ messages in thread From: Jens Axboe @ 2008-12-10 14:11 UTC (permalink / raw) To: Jiri Slaby; +Cc: akpm, linux-kernel, viro, linux-fsdevel On Wed, Dec 10 2008, Jiri Slaby wrote: > Hi, > > on every bootup of this kernel, I get this (not sure if it is right after the moment when / gets mounted from md1): > > wlan0 renamed to wlan1 > udev: renamed network interface wlan0 to wlan1 > swap_cgroup: uses 7848 bytes of vmalloc for pointer array space and 4018176 bytes to hold mem_cgroup pointers on swap > swap_cgroup can be disabled by noswapaccount boot option. > Adding 2008084k swap on /dev/sdb6. Priority:-1 extents:1 across:2008084k > EXT3 FS on md1, internal journal > bio: create slab <bio-1> at 1 > ============================================================================= > BUG bio-1: Redzone overwritten > ----------------------------------------------------------------------------- > > INFO: 0xffff88007bacf068-0xffff88007bacf06f. First byte 0x68 instead of 0xcc > INFO: Allocated in 0x6b6b6b6b6b6b6b6b age=10706345584330245030 cpu=1802201963 pid=1802201963 > INFO: Freed in 0x6b6b6b6b6b6b6b6b age=6527005130130424742 cpu=1802201963 pid=1802201963 > INFO: Slab 0xffffe20001b0dd48 objects=21 used=4 fp=0xffff88007bacf300 flags=0x40000000000000c3 > INFO: Object 0xffff88007bacf000 @offset=0 fp=0x0000000000001000 > > Object 0xffff88007bacf000: fd 6f 57 04 00 00 00 00 00 00 00 00 00 00 00 00 375oW............. > Object 0xffff88007bacf010: 80 86 c2 7c 00 88 ff ff 19 00 00 00 00 00 00 00 ..302|..377377........ > Object 0xffff88007bacf020: 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 ................ > Object 0xffff88007bacf030: 00 00 00 00 00 10 00 00 00 10 00 00 04 00 00 00 ................ > Object 0xffff88007bacf040: ff ff ff ff 00 00 00 00 68 f0 ac 7b 00 88 ff ff 377377377377....h360254{..377377 > Object 0xffff88007bacf050: b0 ad 49 80 ff ff ff ff 58 99 b7 7a 00 88 ff ff 260255I.377377377377X.267z..377377 > Object 0xffff88007bacf060: 10 98 49 80 ff ff ff ff ..I.377377377377 > Redzone 0xffff88007bacf068: 68 1b b1 01 00 e2 ff ff h.261..342377377 > Padding 0xffff88007bacf0a8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ > Padding 0xffff88007bacf0b8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ > Pid: 815, comm: udevd Tainted: G W 2.6.28-rc7-mm1_64 #490 > Call Trace: > <IRQ> [<ffffffff802b6ed6>] print_trailer+0x106/0x160 > [<ffffffff802b7145>] check_bytes_and_report+0x125/0x180 > [<ffffffff802b83d6>] check_object+0x66/0x280 > [<ffffffff802b9e65>] __slab_free+0x225/0x370 > [<ffffffff8028f5d2>] ? mempool_free_slab+0x12/0x20 > [<ffffffff802bb7f2>] kmem_cache_free+0x72/0xa0 > [<ffffffff8028f5d2>] mempool_free_slab+0x12/0x20 > [<ffffffff8028f66a>] mempool_free+0x8a/0xa0 > [<ffffffff802ea03d>] bio_free+0x4d/0x60 > [<ffffffff8049981d>] dm_bio_destructor+0xd/0x10 > [<ffffffff802e848b>] bio_put+0x2b/0x40 > [<ffffffff8049ae39>] clone_endio+0x89/0xd0 > [<ffffffff802e851c>] bio_endio+0x1c/0x40 > [<ffffffff8034f42b>] req_bio_endio+0x8b/0xe0 > [<ffffffff8034f527>] __end_that_request_first+0xa7/0x2b0 > [<ffffffff8034f75c>] end_that_request_data+0x2c/0x70 > [<ffffffff8034f80d>] blk_end_io+0x2d/0xb0 > [<ffffffff8034f8be>] blk_end_request+0xe/0x10 > [<ffffffff80418edb>] scsi_io_completion+0x13b/0x490 > [<ffffffff8041250c>] scsi_finish_command+0xac/0xe0 > [<ffffffff80418d1a>] scsi_softirq_done+0xba/0x140 > [<ffffffff8043df0c>] ? ahci_interrupt+0x9c/0x5c0 > [<ffffffff80353a85>] blk_done_softirq+0x75/0x90 > [<ffffffff8025ab83>] ? sched_clock_cpu+0x143/0x190 > [<ffffffff80244052>] __do_softirq+0xc2/0x190 > [<ffffffff8020d6bc>] call_softirq+0x1c/0x30 > [<ffffffff8020ea15>] do_softirq+0x45/0x90 > [<ffffffff80243d9d>] irq_exit+0x8d/0xa0 > [<ffffffff8020ecc5>] do_IRQ+0xc5/0x110 > [<ffffffff8020cf93>] ret_from_intr+0x0/0xa > <EOI> <3>FIX bio-1: Restoring 0xffff88007bacf068-0xffff88007bacf06f=0xcc > > ============================================================================= > BUG bio-1: Redzone overwritten > ----------------------------------------------------------------------------- > > ffffffff8049981d is in dm_bio_destructor from drivers/md/dm.c. > > Inlined vecs doesn't fit to the allocated slab portion in my eyes, doesn't > the patch below make sense? Ah good, this looks like it's narrowing things down. > Enlarge bio slabs to include inlined vecs > > --- > fs/bio.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/fs/bio.c b/fs/bio.c > index 40b6488..cd1a439 100644 > --- a/fs/bio.c > +++ b/fs/bio.c > @@ -68,7 +68,8 @@ static unsigned int bio_slab_nr, bio_slab_max; > > static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size) > { > - unsigned int sz = sizeof(struct bio) + extra_size; > + unsigned int sz = sizeof(struct bio) + > + sizeof(struct bio_vec) * BIO_INLINE_VECS + extra_size; > struct kmem_cache *slab = NULL; > struct bio_slab *bslab; > unsigned int i, entry = -1; But we already accounted for those bytes at the end. The generic setup does: unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec); ... fs_bio_set = bioset_create(BIO_POOL_SIZE, 0, back_pad); But I notice that you are seeing this with bio-1, not bio-0. So this must be the one of the pools created by md/dm. Does this help? I'll probably rework this a bit, perhaps we should just hide the back padding functionality and force it to be used for vec inlining only. Then it becomes invisible to the users. diff --git a/fs/bio.c b/fs/bio.c index b4008e3..ed9fc15 100644 --- a/fs/bio.c +++ b/fs/bio.c @@ -294,15 +294,20 @@ void bio_init(struct bio *bio) **/ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs) { + unsigned int inline_vecs; struct bio *bio = NULL; if (bs) { void *p = mempool_alloc(bs->bio_pool, gfp_mask); - if (p) + if (p) { bio = p + bs->front_pad; - } else + inline_vecs = bs->inline_vecs; + } + } else { bio = kmalloc(sizeof(*bio), gfp_mask); + inline_vecs = 0; + } if (likely(bio)) { struct bio_vec *bvl = NULL; @@ -311,10 +316,10 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs) if (likely(nr_iovecs)) { unsigned long uninitialized_var(idx); - if (nr_iovecs <= BIO_INLINE_VECS) { + if (nr_iovecs <= inline_vecs) { idx = 0; bvl = bio->bi_inline_vecs; - nr_iovecs = BIO_INLINE_VECS; + nr_iovecs = inline_vecs; } else { bvl = bvec_alloc_bs(gfp_mask, nr_iovecs, &idx, bs); @@ -1605,6 +1610,8 @@ static int __init init_bio(void) if (!fs_bio_set) panic("bio: can't allocate bios\n"); + fs_bio_set->inline_vecs = BIO_INLINE_VECS; + bio_split_pool = mempool_create_kmalloc_pool(BIO_SPLIT_ENTRIES, sizeof(struct bio_pair)); if (!bio_split_pool) diff --git a/include/linux/bio.h b/include/linux/bio.h index fbb62fb..c9f8d26 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -417,6 +417,7 @@ static inline void bio_set_completion_cpu(struct bio *bio, unsigned int cpu) struct bio_set { struct kmem_cache *bio_slab; unsigned int front_pad; + unsigned int inline_vecs; mempool_t *bio_pool; #if defined(CONFIG_BLK_DEV_INTEGRITY) -- Jens Axboe ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: mmotm 2008-12-09-15-24: memory corruption (bio slab) 2008-12-10 14:11 ` Jens Axboe @ 2008-12-10 14:30 ` Jens Axboe 2008-12-10 14:34 ` Jiri Slaby 0 siblings, 1 reply; 4+ messages in thread From: Jens Axboe @ 2008-12-10 14:30 UTC (permalink / raw) To: Jiri Slaby; +Cc: akpm, linux-kernel, viro, linux-fsdevel On Wed, Dec 10 2008, Jens Axboe wrote: > On Wed, Dec 10 2008, Jiri Slaby wrote: > > Hi, > > > > on every bootup of this kernel, I get this (not sure if it is right after the moment when / gets mounted from md1): > > > > wlan0 renamed to wlan1 > > udev: renamed network interface wlan0 to wlan1 > > swap_cgroup: uses 7848 bytes of vmalloc for pointer array space and 4018176 bytes to hold mem_cgroup pointers on swap > > swap_cgroup can be disabled by noswapaccount boot option. > > Adding 2008084k swap on /dev/sdb6. Priority:-1 extents:1 across:2008084k > > EXT3 FS on md1, internal journal > > bio: create slab <bio-1> at 1 > > ============================================================================= > > BUG bio-1: Redzone overwritten > > ----------------------------------------------------------------------------- > > > > INFO: 0xffff88007bacf068-0xffff88007bacf06f. First byte 0x68 instead of 0xcc > > INFO: Allocated in 0x6b6b6b6b6b6b6b6b age=10706345584330245030 cpu=1802201963 pid=1802201963 > > INFO: Freed in 0x6b6b6b6b6b6b6b6b age=6527005130130424742 cpu=1802201963 pid=1802201963 > > INFO: Slab 0xffffe20001b0dd48 objects=21 used=4 fp=0xffff88007bacf300 flags=0x40000000000000c3 > > INFO: Object 0xffff88007bacf000 @offset=0 fp=0x0000000000001000 > > > > Object 0xffff88007bacf000: fd 6f 57 04 00 00 00 00 00 00 00 00 00 00 00 00 375oW............. > > Object 0xffff88007bacf010: 80 86 c2 7c 00 88 ff ff 19 00 00 00 00 00 00 00 ..302|..377377........ > > Object 0xffff88007bacf020: 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 ................ > > Object 0xffff88007bacf030: 00 00 00 00 00 10 00 00 00 10 00 00 04 00 00 00 ................ > > Object 0xffff88007bacf040: ff ff ff ff 00 00 00 00 68 f0 ac 7b 00 88 ff ff 377377377377....h360254{..377377 > > Object 0xffff88007bacf050: b0 ad 49 80 ff ff ff ff 58 99 b7 7a 00 88 ff ff 260255I.377377377377X.267z..377377 > > Object 0xffff88007bacf060: 10 98 49 80 ff ff ff ff ..I.377377377377 > > Redzone 0xffff88007bacf068: 68 1b b1 01 00 e2 ff ff h.261..342377377 > > Padding 0xffff88007bacf0a8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ > > Padding 0xffff88007bacf0b8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ > > Pid: 815, comm: udevd Tainted: G W 2.6.28-rc7-mm1_64 #490 > > Call Trace: > > <IRQ> [<ffffffff802b6ed6>] print_trailer+0x106/0x160 > > [<ffffffff802b7145>] check_bytes_and_report+0x125/0x180 > > [<ffffffff802b83d6>] check_object+0x66/0x280 > > [<ffffffff802b9e65>] __slab_free+0x225/0x370 > > [<ffffffff8028f5d2>] ? mempool_free_slab+0x12/0x20 > > [<ffffffff802bb7f2>] kmem_cache_free+0x72/0xa0 > > [<ffffffff8028f5d2>] mempool_free_slab+0x12/0x20 > > [<ffffffff8028f66a>] mempool_free+0x8a/0xa0 > > [<ffffffff802ea03d>] bio_free+0x4d/0x60 > > [<ffffffff8049981d>] dm_bio_destructor+0xd/0x10 > > [<ffffffff802e848b>] bio_put+0x2b/0x40 > > [<ffffffff8049ae39>] clone_endio+0x89/0xd0 > > [<ffffffff802e851c>] bio_endio+0x1c/0x40 > > [<ffffffff8034f42b>] req_bio_endio+0x8b/0xe0 > > [<ffffffff8034f527>] __end_that_request_first+0xa7/0x2b0 > > [<ffffffff8034f75c>] end_that_request_data+0x2c/0x70 > > [<ffffffff8034f80d>] blk_end_io+0x2d/0xb0 > > [<ffffffff8034f8be>] blk_end_request+0xe/0x10 > > [<ffffffff80418edb>] scsi_io_completion+0x13b/0x490 > > [<ffffffff8041250c>] scsi_finish_command+0xac/0xe0 > > [<ffffffff80418d1a>] scsi_softirq_done+0xba/0x140 > > [<ffffffff8043df0c>] ? ahci_interrupt+0x9c/0x5c0 > > [<ffffffff80353a85>] blk_done_softirq+0x75/0x90 > > [<ffffffff8025ab83>] ? sched_clock_cpu+0x143/0x190 > > [<ffffffff80244052>] __do_softirq+0xc2/0x190 > > [<ffffffff8020d6bc>] call_softirq+0x1c/0x30 > > [<ffffffff8020ea15>] do_softirq+0x45/0x90 > > [<ffffffff80243d9d>] irq_exit+0x8d/0xa0 > > [<ffffffff8020ecc5>] do_IRQ+0xc5/0x110 > > [<ffffffff8020cf93>] ret_from_intr+0x0/0xa > > <EOI> <3>FIX bio-1: Restoring 0xffff88007bacf068-0xffff88007bacf06f=0xcc > > > > ============================================================================= > > BUG bio-1: Redzone overwritten > > ----------------------------------------------------------------------------- > > > > ffffffff8049981d is in dm_bio_destructor from drivers/md/dm.c. > > > > Inlined vecs doesn't fit to the allocated slab portion in my eyes, doesn't > > the patch below make sense? > > Ah good, this looks like it's narrowing things down. > > > Enlarge bio slabs to include inlined vecs > > > > --- > > fs/bio.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/fs/bio.c b/fs/bio.c > > index 40b6488..cd1a439 100644 > > --- a/fs/bio.c > > +++ b/fs/bio.c > > @@ -68,7 +68,8 @@ static unsigned int bio_slab_nr, bio_slab_max; > > > > static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size) > > { > > - unsigned int sz = sizeof(struct bio) + extra_size; > > + unsigned int sz = sizeof(struct bio) + > > + sizeof(struct bio_vec) * BIO_INLINE_VECS + extra_size; > > struct kmem_cache *slab = NULL; > > struct bio_slab *bslab; > > unsigned int i, entry = -1; > > But we already accounted for those bytes at the end. The generic setup > does: > > unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec); > ... > fs_bio_set = bioset_create(BIO_POOL_SIZE, 0, back_pad); > > But I notice that you are seeing this with bio-1, not bio-0. So this > must be the one of the pools created by md/dm. Does this help? > > I'll probably rework this a bit, perhaps we should just hide the back > padding functionality and force it to be used for vec inlining only. > Then it becomes invisible to the users. Something like this, I'll fold it into the original patch. diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index b6b1b80..3326750 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -1060,7 +1060,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv) goto bad_page_pool; } - cc->bs = bioset_create(MIN_IOS, 0, 0); + cc->bs = bioset_create(MIN_IOS, 0); if (!cc->bs) { ti->error = "Cannot allocate crypt bioset"; goto bad_bs; diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c index eb518b8..a343385 100644 --- a/drivers/md/dm-io.c +++ b/drivers/md/dm-io.c @@ -56,7 +56,7 @@ struct dm_io_client *dm_io_client_create(unsigned num_pages) if (!client->pool) goto bad; - client->bios = bioset_create(16, 0, 0); + client->bios = bioset_create(16, 0); if (!client->bios) goto bad; diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 35975a4..368ffa3 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1091,7 +1091,7 @@ static struct mapped_device *alloc_dev(int minor) if (!md->tio_pool) goto bad_tio_pool; - md->bs = bioset_create(16, 0, 0); + md->bs = bioset_create(16, 0); if (!md->bs) goto bad_no_bioset; diff --git a/fs/bio.c b/fs/bio.c index b4008e3..45ddca4 100644 --- a/fs/bio.c +++ b/fs/bio.c @@ -1519,19 +1519,18 @@ void bioset_free(struct bio_set *bs) * bioset_create - Create a bio_set * @pool_size: Number of bio and bio_vecs to cache in the mempool * @front_pad: Number of bytes to allocate in front of the returned bio - * @back_pad: Number of bytes to allocate behind the returned bio * * Description: * Set up a bio_set to be used with @bio_alloc_bioset. Allows the caller - * to ask for a number of bytes to be allocated in front and back of the - * bio. Front pad allocation is useful for embedding the bio inside + * to ask for a number of bytes to be allocated in front of the bio. + * Front pad allocation is useful for embedding the bio inside * another structure, to avoid allocating extra data to go with the bio. * Note that the bio must be embedded at the END of that structure always, - * or things will break badly if back padding is also used. + * or things will break badly. */ -struct bio_set *bioset_create(unsigned int pool_size, unsigned int front_pad, - unsigned int back_pad) +struct bio_set *bioset_create(unsigned int pool_size, unsigned int front_pad) { + unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec); struct bio_set *bs; bs = kzalloc(sizeof(*bs), GFP_KERNEL); @@ -1584,8 +1583,6 @@ static void __init biovec_init_slabs(void) static int __init init_bio(void) { - unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec); - bio_slab_max = 2; bio_slab_nr = 0; bio_slabs = kzalloc(bio_slab_max * sizeof(struct bio_slab), GFP_KERNEL); @@ -1595,13 +1592,7 @@ static int __init init_bio(void) bio_integrity_init_slab(); biovec_init_slabs(); - if (back_pad) { - printk(KERN_INFO "bio: Using %d inlines, %u -> %u bytes\n", - BIO_INLINE_VECS, (int) sizeof(struct bio), - (int) sizeof(struct bio) + back_pad); - } - - fs_bio_set = bioset_create(BIO_POOL_SIZE, 0, back_pad); + fs_bio_set = bioset_create(BIO_POOL_SIZE, 0); if (!fs_bio_set) panic("bio: can't allocate bios\n"); diff --git a/include/linux/bio.h b/include/linux/bio.h index fbb62fb..76134d7 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -348,7 +348,7 @@ struct bio_pair { extern struct bio_pair *bio_split(struct bio *bi, int first_sectors); extern void bio_pair_release(struct bio_pair *dbio); -extern struct bio_set *bioset_create(unsigned int, unsigned int, unsigned int); +extern struct bio_set *bioset_create(unsigned int, unsigned int); extern void bioset_free(struct bio_set *); extern struct bio *bio_alloc(gfp_t, int); -- Jens Axboe ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: mmotm 2008-12-09-15-24: memory corruption (bio slab) 2008-12-10 14:30 ` Jens Axboe @ 2008-12-10 14:34 ` Jiri Slaby 0 siblings, 0 replies; 4+ messages in thread From: Jiri Slaby @ 2008-12-10 14:34 UTC (permalink / raw) To: Jens Axboe; +Cc: akpm, linux-kernel, viro, linux-fsdevel On 12/10/2008 03:30 PM, Jens Axboe wrote: > On Wed, Dec 10 2008, Jens Axboe wrote: >> But I notice that you are seeing this with bio-1, not bio-0. So this >> must be the one of the pools created by md/dm. Does this help? >> >> I'll probably rework this a bit, perhaps we should just hide the back >> padding functionality and force it to be used for vec inlining only. >> Then it becomes invisible to the users. > > Something like this, I'll fold it into the original patch. Seems OK. The first patch fixes the issue, indeed. Thanks. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-12-10 14:35 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-12-10 13:57 mmotm 2008-12-09-15-24: memory corruption (bio slab) Jiri Slaby 2008-12-10 14:11 ` Jens Axboe 2008-12-10 14:30 ` Jens Axboe 2008-12-10 14:34 ` Jiri Slaby
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox