Thread (71 messages) 71 messages, 7 authors, 2012-08-15

Re: [PATCH v5 05/12] block: Kill bi_destructor

From: Kent Overstreet <hidden>
Date: 2012-08-15 22:19:42
Also in: dm-devel, lkml

On Wed, Aug 08, 2012 at 11:34:09PM -0700, Tejun Heo wrote:
Hello,

On Wed, Aug 8, 2012 at 11:12 PM, Kent Overstreet [off-list ref] wrote:
quoted
But if it's a pointer to heap allocated memory, but the bio was embedded
in another struct? I've seen a fair number of instances of that (md, off
the top of my head).

If you're sure that in a normal config the slab allocator is going to
complain right away and not corrupt itself, fine. But I've been bitten
way too hard by bugs that could've been caught right away by a simple
assert and instead I had to spend hours backtracking, and the block
layer is _rife_ with that kind of thing.
Let's let slab debug code deal with that.  I really don't see much
benefit in doing this.  The said kind of bugs aren't particularly
difficult to track down.
The only difference would be changing
#define BIO_KMALLOC_POOL ((void *) ~0)

to
#define BIO_KMALLOC_POOL NULL

We want a define for this - bio_alloc_bioset(GFP_KERNEL, 1, NULL)
doesn't make any sense. I just don't see the argument for changing an
arbitrary constant... If it's just the ~0 pointer you don't like, I
originally used a real statically allocated struct bio_set as a sentinel
value.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help