From: Sergei Shtepa <sergei.shtepa@veeam.com> To: Christoph Hellwig <hch@infradead.org> Cc: Mike Snitzer <snitzer@redhat.com>, Alasdair Kergon <agk@redhat.com>, Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, Pavel Tide <Pavel.TIde@veeam.com> Subject: Re: [PATCH v7 2/3] block: add bdev_interposer Date: Mon, 15 Mar 2021 16:06:13 +0300 [thread overview] Message-ID: <20210315130613.GC30489@veeam.com> (raw) In-Reply-To: <20210314092823.GB3773360@infradead.org> The 03/14/2021 12:28, Christoph Hellwig wrote: > On Fri, Mar 12, 2021 at 06:44:54PM +0300, Sergei Shtepa wrote: > > bdev_interposer allows to redirect bio requests to another devices. > > I think this warrants a somewhat more detailed description. > > The code itself looks pretty good to me now, a bunch of nitpicks and > a question below: > > > +static noinline blk_qc_t submit_bio_interposed(struct bio *bio) > > +{ > > + blk_qc_t ret = BLK_QC_T_NONE; > > + struct bio_list bio_list[2] = { }; > > + struct gendisk *orig_disk; > > + > > + if (current->bio_list) { > > + bio_list_add(¤t->bio_list[0], bio); > > + return BLK_QC_T_NONE; > > + } > > I don't think this case can ever happen: > > - current->bio_list != NULL means a ->submit_bio or blk_mq_submit_bio > is active. But if this device is being interposed this means the > interposer recurses into itself, which should never happen. So > I think we'll want a WARN_ON_ONCE here as a debug check instead. Yes, it is. Completely remove this check or add "BUG_ON(current->bio_list);" for an emergency? > > > + > > + orig_disk = bio->bi_bdev->bd_disk; > > + if (unlikely(bio_queue_enter(bio))) > > + return BLK_QC_T_NONE; > > + > > + current->bio_list = bio_list; > > + > > + do { > > + struct block_device *interposer = bio->bi_bdev->bd_interposer; > > + > > + if (unlikely(!interposer)) { > > + /* interposer was removed */ > > + bio_list_add(¤t->bio_list[0], bio); > > + break; > > + } > > + /* assign bio to interposer device */ > > + bio_set_dev(bio, interposer); > > + bio_set_flag(bio, BIO_INTERPOSED); > > Reassigning the bi_bdev here means the original source is lost by the > time we reach the interposer. This initially seemed a little limiting, > but I guess the interposer driver can just record that information > locally, so we should be fine. The big upside of this is that no > extra argument to submit_bio_checks, which means less changes to the > normal fast path, so if this works for everyone that is a nice > improvement over my draft. > > > + > > + if (!submit_bio_checks(bio)) > > + break; > > + /* > > + * Because the current->bio_list is initialized, > > + * the submit_bio callback will always return BLK_QC_T_NONE. > > + */ > > + interposer->bd_disk->fops->submit_bio(bio); > > + } while (false); > > I find the do { ... } while (false) idiom here a little strange. Normal > kernel style would be a goto done instead of the breaks. > Ok. I'll use the normal kernel style. > > +int bdev_interposer_attach(struct block_device *original, > > + struct block_device *interposer) > > A kerneldoc comment for bdev_interposer_attach (and > bdev_interposer_detach) would be nice to explain the API a little more. > Yes, I should add kerneldoc comments. > > +{ > > + int ret = 0; > > + > > + if (WARN_ON(((!original) || (!interposer)))) > > + return -EINVAL; > > No need for the inner two levels of braces. Ok. > > > + * interposer should be simple, no a multi-queue device > > + */ > > + if (!interposer->bd_disk->fops->submit_bio) > > Please use queue_is_mq() instead. Ok. > > > + if (bdev_has_interposer(original)) > > + ret = -EBUSY; > > + else { > > + original->bd_interposer = bdgrab(interposer); > > Just thinking out a loud: what happens if the interposed device > goes away? Shouldn't we at very least also make sure this > gabs another refererence on bdev as well? If the original device is removed from the system, the interposer device will be permanently occupied. I need to add an interposer release when deleting a block device. > > > +struct bdev_interposer; > > Not needed any more. Yes. > > > +static inline bool bdev_has_interposer(struct block_device *bdev) > > +{ > > + return (bdev->bd_interposer != NULL); > > +}; > > No need for the braces. Ok. -- Sergei Shtepa Veeam Software developer.
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtepa <sergei.shtepa@veeam.com> To: Christoph Hellwig <hch@infradead.org> Cc: Jens Axboe <axboe@kernel.dk>, Mike Snitzer <snitzer@redhat.com>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, Pavel Tide <Pavel.TIde@veeam.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "dm-devel@redhat.com" <dm-devel@redhat.com>, Alasdair Kergon <agk@redhat.com> Subject: Re: [dm-devel] [PATCH v7 2/3] block: add bdev_interposer Date: Mon, 15 Mar 2021 16:06:13 +0300 [thread overview] Message-ID: <20210315130613.GC30489@veeam.com> (raw) In-Reply-To: <20210314092823.GB3773360@infradead.org> The 03/14/2021 12:28, Christoph Hellwig wrote: > On Fri, Mar 12, 2021 at 06:44:54PM +0300, Sergei Shtepa wrote: > > bdev_interposer allows to redirect bio requests to another devices. > > I think this warrants a somewhat more detailed description. > > The code itself looks pretty good to me now, a bunch of nitpicks and > a question below: > > > +static noinline blk_qc_t submit_bio_interposed(struct bio *bio) > > +{ > > + blk_qc_t ret = BLK_QC_T_NONE; > > + struct bio_list bio_list[2] = { }; > > + struct gendisk *orig_disk; > > + > > + if (current->bio_list) { > > + bio_list_add(¤t->bio_list[0], bio); > > + return BLK_QC_T_NONE; > > + } > > I don't think this case can ever happen: > > - current->bio_list != NULL means a ->submit_bio or blk_mq_submit_bio > is active. But if this device is being interposed this means the > interposer recurses into itself, which should never happen. So > I think we'll want a WARN_ON_ONCE here as a debug check instead. Yes, it is. Completely remove this check or add "BUG_ON(current->bio_list);" for an emergency? > > > + > > + orig_disk = bio->bi_bdev->bd_disk; > > + if (unlikely(bio_queue_enter(bio))) > > + return BLK_QC_T_NONE; > > + > > + current->bio_list = bio_list; > > + > > + do { > > + struct block_device *interposer = bio->bi_bdev->bd_interposer; > > + > > + if (unlikely(!interposer)) { > > + /* interposer was removed */ > > + bio_list_add(¤t->bio_list[0], bio); > > + break; > > + } > > + /* assign bio to interposer device */ > > + bio_set_dev(bio, interposer); > > + bio_set_flag(bio, BIO_INTERPOSED); > > Reassigning the bi_bdev here means the original source is lost by the > time we reach the interposer. This initially seemed a little limiting, > but I guess the interposer driver can just record that information > locally, so we should be fine. The big upside of this is that no > extra argument to submit_bio_checks, which means less changes to the > normal fast path, so if this works for everyone that is a nice > improvement over my draft. > > > + > > + if (!submit_bio_checks(bio)) > > + break; > > + /* > > + * Because the current->bio_list is initialized, > > + * the submit_bio callback will always return BLK_QC_T_NONE. > > + */ > > + interposer->bd_disk->fops->submit_bio(bio); > > + } while (false); > > I find the do { ... } while (false) idiom here a little strange. Normal > kernel style would be a goto done instead of the breaks. > Ok. I'll use the normal kernel style. > > +int bdev_interposer_attach(struct block_device *original, > > + struct block_device *interposer) > > A kerneldoc comment for bdev_interposer_attach (and > bdev_interposer_detach) would be nice to explain the API a little more. > Yes, I should add kerneldoc comments. > > +{ > > + int ret = 0; > > + > > + if (WARN_ON(((!original) || (!interposer)))) > > + return -EINVAL; > > No need for the inner two levels of braces. Ok. > > > + * interposer should be simple, no a multi-queue device > > + */ > > + if (!interposer->bd_disk->fops->submit_bio) > > Please use queue_is_mq() instead. Ok. > > > + if (bdev_has_interposer(original)) > > + ret = -EBUSY; > > + else { > > + original->bd_interposer = bdgrab(interposer); > > Just thinking out a loud: what happens if the interposed device > goes away? Shouldn't we at very least also make sure this > gabs another refererence on bdev as well? If the original device is removed from the system, the interposer device will be permanently occupied. I need to add an interposer release when deleting a block device. > > > +struct bdev_interposer; > > Not needed any more. Yes. > > > +static inline bool bdev_has_interposer(struct block_device *bdev) > > +{ > > + return (bdev->bd_interposer != NULL); > > +}; > > No need for the braces. Ok. -- Sergei Shtepa Veeam Software developer. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-03-15 13:07 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-12 15:44 [PATCH v7 0/3] block device interposer Sergei Shtepa 2021-03-12 15:44 ` [dm-devel] " Sergei Shtepa 2021-03-12 15:44 ` [PATCH v7 1/3] block: add blk_mq_is_queue_frozen() Sergei Shtepa 2021-03-12 15:44 ` [dm-devel] " Sergei Shtepa 2021-03-12 19:06 ` Mike Snitzer 2021-03-12 19:06 ` [dm-devel] " Mike Snitzer 2021-03-14 9:14 ` Christoph Hellwig 2021-03-14 9:14 ` [dm-devel] " Christoph Hellwig 2021-03-15 12:06 ` Sergei Shtepa 2021-03-15 12:06 ` [dm-devel] " Sergei Shtepa 2021-03-12 15:44 ` [PATCH v7 2/3] block: add bdev_interposer Sergei Shtepa 2021-03-12 15:44 ` [dm-devel] " Sergei Shtepa 2021-03-14 9:28 ` Christoph Hellwig 2021-03-14 9:28 ` [dm-devel] " Christoph Hellwig 2021-03-15 13:06 ` Sergei Shtepa [this message] 2021-03-15 13:06 ` Sergei Shtepa 2021-03-16 8:09 ` Ming Lei 2021-03-16 8:09 ` [dm-devel] " Ming Lei 2021-03-16 16:35 ` Sergei Shtepa 2021-03-16 16:35 ` [dm-devel] " Sergei Shtepa 2021-03-17 3:03 ` Ming Lei 2021-03-17 3:03 ` [dm-devel] " Ming Lei 2021-03-17 12:22 ` Sergei Shtepa 2021-03-17 12:22 ` [dm-devel] " Sergei Shtepa 2021-03-17 15:04 ` Mike Snitzer 2021-03-17 15:04 ` [dm-devel] " Mike Snitzer 2021-03-17 18:14 ` Sergei Shtepa 2021-03-17 18:14 ` [dm-devel] " Sergei Shtepa 2021-03-17 19:13 ` Mike Snitzer 2021-03-17 19:13 ` [dm-devel] " Mike Snitzer 2021-03-18 14:56 ` Sergei Shtepa 2021-03-18 14:56 ` [dm-devel] " Sergei Shtepa 2021-03-17 14:58 ` Mike Snitzer 2021-03-17 14:58 ` [dm-devel] " Mike Snitzer 2021-03-12 15:44 ` [PATCH v7 3/3] dm: add DM_INTERPOSED_FLAG Sergei Shtepa 2021-03-12 15:44 ` [dm-devel] " Sergei Shtepa 2021-03-12 19:00 ` Mike Snitzer 2021-03-12 19:00 ` [dm-devel] " Mike Snitzer 2021-03-15 12:29 ` Sergei Shtepa 2021-03-15 12:29 ` [dm-devel] " Sergei Shtepa 2021-03-14 9:30 ` Christoph Hellwig 2021-03-14 9:30 ` [dm-devel] " Christoph Hellwig 2021-03-15 13:25 ` Sergei Shtepa 2021-03-15 13:25 ` [dm-devel] " Sergei Shtepa 2021-03-16 15:23 ` Christoph Hellwig 2021-03-16 15:23 ` [dm-devel] " Christoph Hellwig 2021-03-16 15:25 ` Christoph Hellwig 2021-03-16 15:25 ` [dm-devel] " Christoph Hellwig 2021-03-16 16:20 ` Sergei Shtepa 2021-03-16 16:20 ` [dm-devel] " Sergei Shtepa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210315130613.GC30489@veeam.com \ --to=sergei.shtepa@veeam.com \ --cc=Pavel.TIde@veeam.com \ --cc=agk@redhat.com \ --cc=axboe@kernel.dk \ --cc=dm-devel@redhat.com \ --cc=hare@suse.de \ --cc=hch@infradead.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=snitzer@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.