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 <koverstreet@xxxxxxxxxx> wrote: > > 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
