Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932327AbbERP76 (ORCPT ); Mon, 18 May 2015 11:59:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751435AbbERP7t (ORCPT ); Mon, 18 May 2015 11:59:49 -0400 Date: Mon, 18 May 2015 11:59:48 -0400 From: Mike Snitzer To: Jan Kara Cc: Jens Axboe , Chris Mason , dm-devel@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH for-4.2 01/14] block: remove management of bi_remaining when restoring original bi_end_io Message-ID: <20150518155948.GE13998@redhat.com> References: <1431637512-64245-1-git-send-email-snitzer@redhat.com> <1431637512-64245-2-git-send-email-snitzer@redhat.com> <20150518072237.GE26351@quack.suse.cz> <20150518131358.GA13998@redhat.com> <20150518153644.GA10187@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150518153644.GA10187@quack.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1669 Lines: 34 On Mon, May 18 2015 at 11:36am -0400, Jan Kara wrote: > No, I'm not referring to your proposed interface. I'm referring to > current kernel + your patch to remove bio_inc_remaining() from all the dm > targets. Ah, after checking again I see where misunderstanding may have > come from - the device below has to be handled by drivers/md/linear.c which > is MD linear driver, not DM one. I confused those two. Anyway here is the > failure I envision (and frankly, I don't understand dm details much so I may > be just completely wrong but I'd like to understand what prevents the following > from happening): > * We have dm-thin stacked on top of drivers/dm/linear.c > * FS issues bio to dm-thin. remap_and_issue_overwrite() sets bi_end_io to > overwrite_endio. dm-thin eventually calls generic_make_request(bio). > * Now linear_make_request() gets called and it ends up calling > bio_chain(split, bio). This sets BIO_CHAIN on bio. > * IO for all chained bios is completed. So bio->bi_remaining is now zero, > bio still has BIO_CHAIN set and overwrite_endio gets called. > * process_prepared_mapping() will eventually try to call original bi_end_io > callback but that never happens because bi_remaining is 0 and BIO_CHAIN > remained set. Makes sense, you have a valid concern (I knew you and hch must, I just didn't understand). I'll clear the BIO_CHAIN like you suggest and post v2. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/