- Subject: Re: [PATCH v5 05/12] block: Kill bi_destructor
- From: Tejun Heo <tj@xxxxxxxxxx>
- Date: Wed, 8 Aug 2012 23:34:09 -0700
- Cc: axboe@xxxxxxxxx, dm-devel@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-bcache@xxxxxxxxxxxxxxx, mpatocka@xxxxxxxxxx, vgoyal@xxxxxxxxxx, yehuda@xxxxxxxxxxxxxxx, sage@xxxxxxxxxxxx, agk@xxxxxxxxxx, drbd-dev@xxxxxxxxxxxxxxxx
- In-reply-to: <20120809061214.GA9128@dhcp-172-18-216-138.mtv.corp.google.com>
- References: <1344290921-25154-1-git-send-email-koverstreet@google.com> <1344290921-25154-6-git-send-email-koverstreet@google.com> <20120808222223.GD6983@dhcp-172-17-108-109.mtv.corp.google.com> <20120809002154.GE7262@moria.home.lan> <20120809060517.GB2845@dhcp-172-17-108-109.mtv.corp.google.com> <20120809061214.GA9128@dhcp-172-18-216-138.mtv.corp.google.com>
- Reply-to: device-mapper development <dm-devel@xxxxxxxxxx>
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.
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
[DM Crypt]
[Fedora Desktop]
[ATA RAID]
[Fedora Marketing]
[Fedora Packaging]
[Fedora SELinux]
[Yosemite Discussion]
[Yosemite Photos]
[KDE Users]
[Fedora Tools]
[Fedora Docs]