Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8689777imu; Tue, 4 Dec 2018 12:30:12 -0800 (PST) X-Google-Smtp-Source: AFSGD/UuYCTHxdbc+4pLwuHxV77JRIYKIjHTgR37fAa+QQdgEYI8D3fYEdjURoA53gHcq8kpgiHK X-Received: by 2002:a63:7044:: with SMTP id a4mr16512480pgn.359.1543955412582; Tue, 04 Dec 2018 12:30:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543955412; cv=none; d=google.com; s=arc-20160816; b=Txol6+ovXJXxWn9WTBMecMHv8hPPPmneI1jZVIFadMFv8ttKUNp0fUW5F/AdYQZAX6 +BdNwxD/NUIO6YKh49GsEEAY1dqLMnx0ey+mdvYWkzeGu7UVtu7gKIEPmH/ne4asAIvG RHjUOYUC4I1c1/JjztBpwxi8UBBp1cbhDzh8YwE6JKXYqzMn0g49SVtxfbBHEAyhiywq Diuluy7VDYrvr7a/DIMVruNOHIKcmjeglfnjRl+NWESZcY6jCb6K4LwWgay8FuziYx0W z4B/bzRndwXKX3+BoutbgmRxTvJbbVxeZyStVfn04+eds4HvbueX7kwujWMRjq+rU66w EqOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pvHymNpPf1LQWlj0hQV41rvoc6arbBFGYXX43yIjEHQ=; b=xCNpO2JhAf34C4mtp2/TdxLrD9ETFh2xZlri2Qagam/EhWBjIDYTOK4hSCKXuvdL1H DLxV+fCPRy/6MczI0PrbIUAA+mGSlI2/VLM5n5TvzPe9TyjKSjlyJ/HR9JMbtap9Cof5 pP7km1NQybELdqVn5r16gksaz9QEl0xjw4mWLrY0Bbst7uirQrpWxZKy7h/on+3Jyn4D t9CVeIKCQMY5SWSLR/ody6HN/D0Vjiar+NSlZp5+lktShsGbCwrd6lKWbVkBhhKi5c7Y Wmo8McUb99FhDQMWUBeF7rdSqvddpCTjxZTDHWyhZ+3bbwL6bf9vHyrteF0HnBAch616 mZQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x23si16864479pln.100.2018.12.04.12.29.57; Tue, 04 Dec 2018 12:30:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726240AbeLDU2K (ORCPT + 99 others); Tue, 4 Dec 2018 15:28:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50112 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbeLDU2K (ORCPT ); Tue, 4 Dec 2018 15:28:10 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2CEECBDD1; Tue, 4 Dec 2018 20:28:09 +0000 (UTC) Received: from localhost (unknown [10.18.25.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A1B9B5C21C; Tue, 4 Dec 2018 20:28:08 +0000 (UTC) Date: Tue, 4 Dec 2018 15:28:07 -0500 From: Mike Snitzer To: Dennis Zhou Cc: Jens Axboe , Tejun Heo , Johannes Weiner , Josef Bacik , kernel-team@fb.com, linux-block@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Alasdair Kergon Subject: Re: [PATCH 05/14] dm: set the static flush bio device on demand Message-ID: <20181204202807.GA4689@redhat.com> References: <20181204183600.99746-1-dennis@kernel.org> <20181204183600.99746-6-dennis@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181204183600.99746-6-dennis@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 04 Dec 2018 20:28:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 04 2018 at 1:35pm -0500, Dennis Zhou wrote: > The next patch changes the macro bio_set_dev() to associate a bio with a > blkg based on the device set. However, dm creates a static bio to be > used as the basis for cloning empty flush bios on creation. The > bio_set_dev() call in alloc_dev() will cause problems with the next > patch adding association to bio_set_dev() because the call is before the > bdev is associated with a gendisk (bd_disk is %NULL). To get around > this, set the device on the static bio every time and use that to clone > to the other bios. > > Signed-off-by: Dennis Zhou > Cc: Alasdair Kergon > Cc: Mike Snitzer > --- > block/bio.c | 1 + > drivers/md/dm.c | 12 +++++++++++- > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/block/bio.c b/block/bio.c > index 452b8e79b998..41ebb3f8e2fc 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -2021,6 +2021,7 @@ void bio_disassociate_blkg(struct bio *bio) > bio->bi_blkg = NULL; > } > } > +EXPORT_SYMBOL_GPL(bio_disassociate_blkg); > > /** > * __bio_associate_blkg - associate a bio with the a blkg > diff --git a/drivers/md/dm.c b/drivers/md/dm.c > index a733e4c920af..a2d6f8b33d23 100644 > --- a/drivers/md/dm.c > +++ b/drivers/md/dm.c > @@ -1417,10 +1417,21 @@ static int __send_empty_flush(struct clone_info *ci) > unsigned target_nr = 0; > struct dm_target *ti; > > + /* > + * Empty flush uses a statically initialized bio as the base for > + * cloning, &md->flush_bio. However, blkg association requires that Would prefer: "Empty flush uses a statically initialized bio, &md->flush_bio, as the base for cloning. ..." > + * a bdev is associated with a gendisk, which doesn't happen until the > + * bdev is opened. So, blkg association is done at issue time of the > + * flush rather than when the device is created in dm_alloc(). Another nit but I think you mean "alloc_dev()" here .......^ > + */ > + bio_set_dev(ci->bio, ci->io->md->bdev); > + > BUG_ON(bio_has_data(ci->bio)); > while ((ti = dm_table_get_target(ci->map, target_nr++))) > __send_duplicate_bios(ci, ti, ti->num_flush_bios, NULL); > > + bio_disassociate_blkg(ci->bio); > + > return 0; > } > > @@ -1939,7 +1950,6 @@ static struct mapped_device *alloc_dev(int minor) > goto bad; > > bio_init(&md->flush_bio, NULL, 0); > - bio_set_dev(&md->flush_bio, md->bdev); > md->flush_bio.bi_opf = REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC; > > dm_stats_init(&md->stats); The top-level DM device's bdev->bd_disk is only assigned after the first blkdev_get(), so I can see why this is needed. Think this type of life-cycle quirk was the kind of thing that caused blk cgroup issues with DM. Left wondering whether there would be a better way of handling N flush bios for DM devices. But for the now this will have to do. Acked-by: Mike Snitzer Thanks, Mike