linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Sergei Shtepa <sergei.shtepa@veeam.com>
Cc: axboe@kernel.dk, corbet@lwn.net, linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 09/21] block, blksnap: attaching and detaching the filter and handling I/O units
Date: Thu, 15 Dec 2022 02:01:15 -0800	[thread overview]
Message-ID: <Y5rwa6m3yqo40vz1@infradead.org> (raw)
In-Reply-To: <20221209142331.26395-10-sergei.shtepa@veeam.com>

> +static bool tracker_submit_bio_cb(struct bio *bio)
> +{
> +	struct bdev_filter *flt = bio->bi_bdev->bd_filter;
> +	struct bio_list bio_list_on_stack[2] = { };
> +	struct bio *new_bio;
> +	bool ret = true;
> +	struct tracker *tracker = container_of(flt, struct tracker, flt);
> +	int err;
> +	sector_t sector;
> +	sector_t count;
> +	unsigned int current_flag;
> +
> +	WARN_ON_ONCE(!flt);
> +	if (unlikely(!flt))
> +		return true;

We're called through the filter, so checking this again here (twice)
is a bit silly.

> +	if (bio->bi_opf & REQ_NOWAIT) {
> +		if (!percpu_down_read_trylock(&tracker_submit_lock)) {
> +			bio_wouldblock_error(bio);
> +			return false;
> +		}
> +	} else
> +		percpu_down_read(&tracker_submit_lock);

Does it make sense to make this a global lock vs per-struct tracker?

> +	if (!op_is_write(bio_op(bio)))
> +		goto out;
> +
> +	count = bio_sectors(bio);
> +	if (!count)
> +		goto out;

Just nitpicking, but what about moving all the code below here
into a separate helper that is only called for op_is_write &&
bio_sectors?  It's not going to change anything functionally, but
would make the code easier to follow.

> +	current_flag = memalloc_noio_save();
> +	bio_list_init(&bio_list_on_stack[0]);
> +	current->bio_list = bio_list_on_stack;
> +	barrier();

barrier is just a compiler barrier, so it is unlikely to do what
you want. But without a comment I can't even figure out what it is
trying to do.

> +static int tracker_filter_attach(struct block_device *bdev,
> +				 struct tracker *tracker)
> +{
> +	int ret;
> +	bool is_frozen = false;
> +
> +	pr_debug("Tracker attach filter\n");
> +
> +	if (freeze_bdev(bdev))
> +		pr_err("Failed to freeze device [%u:%u]\n", MAJOR(bdev->bd_dev),
> +		       MINOR(bdev->bd_dev));

I think you need to fail the attachment if we can't freeze the device.

> +static int tracker_filter_detach(struct block_device *bdev)
> +{
> +	int ret;
> +	bool is_frozen = false;
> +
> +	pr_debug("Tracker delete filter\n");
> +	if (freeze_bdev(bdev))
> +		pr_err("Failed to freeze device [%u:%u]\n", MAJOR(bdev->bd_dev),
> +		       MINOR(bdev->bd_dev));

Same here.

> +/**
> + * tracker_wait_for_release - Waiting for all trackers are released.
> + *
> + * Trackers are released in the worker thread. So, this function allows to wait
> + * for the end of the process of releasing trackers.
> + */
> +static void tracker_wait_for_release(void)

This defeats the reason to move it to the workqueue first, as you
can still deadlock on whatever problem that tried to solve, just
out of reach of lockdep.

> +struct tracker *tracker_create_or_get(dev_t dev_id)
> +{
> +	struct tracker *tracker;
> +	struct block_device *bdev;
> +	struct tracked_device *tr_dev;
> +
> +	bdev = blkdev_get_by_dev(dev_id, 0, NULL);

These blkdev_get_by_dev calls are a little problematic, as they
bypass any access restriction (LSMs, containers, etc).  That's
why the kernel generally does a blkdev_get_by_name based on the
actual file name, which does all the proper checks.  I think the
tracker creation also needs to happen based on names to fit into this
security model.  Passing in names should also be much easier for
userspace to start with.


Now for remove, and the other operations on the tracked device:
Is there any reason to not simply add an ioctl method to
bdev_filter_operations, so that you can issue these ioctls against the
tracked device?  That removes the need to find the tracked device
entirely and should simplify a lot of things.

In fact thinking wonder if attachment of a filter driver should
go through the block layer using an ioctl on the tracked device
as well, i.e.

 - add a name field to bdev_filter_operations
 - keep a list of all bdev_filter_operations in the block core
 - new core block layer ioctl to associate a block device with a
   bdev_filter_operations
 - everything after that is done through bdev_filter_operations->ioctl.


  reply	other threads:[~2022-12-15 10:01 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09 14:23 [PATCH v2 00/21] blksnap - block devices snapshots module Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 01/21] documentation, blkfilter: Block Device Filtering Mechanism Sergei Shtepa
2022-12-10  4:15   ` Bagas Sanjaya
2022-12-09 14:23 ` [PATCH v2 02/21] block, " Sergei Shtepa
2022-12-15  9:26   ` Christoph Hellwig
2022-12-15 10:46     ` Sergei Shtepa
2022-12-16  7:04       ` Christoph Hellwig
2023-01-31 23:58   ` Mike Snitzer
2023-02-01 11:09     ` Fabio Fantoni
2023-02-01 13:16     ` Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 03/21] documentation, capability: fix Generic Block Device Capability Sergei Shtepa
2022-12-13 12:13   ` Fabio Fantoni
2022-12-30 15:35     ` Fabio Fantoni
2022-12-09 14:23 ` [PATCH v2 04/21] documentation, blksnap: Block Devices Snapshots Module Sergei Shtepa
2022-12-10  3:50   ` Bagas Sanjaya
2022-12-09 14:23 ` [PATCH v2 05/21] block, blksnap: header file of the module interface Sergei Shtepa
2022-12-09 22:13   ` kernel test robot
2022-12-09 23:14   ` kernel test robot
2022-12-09 14:23 ` [PATCH v2 06/21] block, blksnap: module management interface functions Sergei Shtepa
2022-12-15  9:28   ` Christoph Hellwig
     [not found]   ` <CGME20230103153406eucas1p205c48bd767e6a86f6f1121db7eb5fc19@eucas1p2.samsung.com>
2023-01-03 15:26     ` Pankaj Raghav
2022-12-09 14:23 ` [PATCH v2 07/21] block, blksnap: init() and exit() functions Sergei Shtepa
2022-12-15  9:30   ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 08/21] block, blksnap: interaction with sysfs Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 09/21] block, blksnap: attaching and detaching the filter and handling I/O units Sergei Shtepa
2022-12-15 10:01   ` Christoph Hellwig [this message]
2022-12-09 14:23 ` [PATCH v2 10/21] block, blksnap: map of change block tracking Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 11/21] block, blksnap: minimum data storage unit of the original block device Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 12/21] block, blksnap: buffer in memory for the minimum data storage unit Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 13/21] block, blksnap: functions and structures for performing block I/O operations Sergei Shtepa
2022-12-15 10:06   ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 14/21] block, blksnap: storage for storing difference blocks Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 15/21] block, blksnap: event queue from the difference storage Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 16/21] block, blksnap: owner of information about overwritten blocks of the original block device Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 17/21] block, blksnap: snapshot image " Sergei Shtepa
2022-12-15  9:45   ` Christoph Hellwig
2022-12-09 14:23 ` [PATCH v2 18/21] block, blksnap: snapshot Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 19/21] block, blksnap: Kconfig and Makefile Sergei Shtepa
2022-12-09 14:23 ` [PATCH v2 20/21] block, blksnap: adds a blksnap to the kernel tree Sergei Shtepa
2022-12-09 21:53   ` kernel test robot
2022-12-09 14:23 ` [PATCH v2 21/21] block, blksnap: adds a maintainer for new files Sergei Shtepa
2022-12-10  3:23 ` [PATCH v2 00/21] blksnap - block devices snapshots module Bagas Sanjaya
2022-12-10 22:57   ` Sergei Shtepa
     [not found] ` <20230101071813.3329-1-hdanton@sina.com>
2023-01-02  9:44   ` [PATCH v2 17/21] block, blksnap: snapshot image block device Sergei Shtepa
     [not found] ` <20230101110542.3395-1-hdanton@sina.com>
2023-01-02  9:58   ` [PATCH v2 18/21] block, blksnap: snapshot Sergei Shtepa
2023-01-17 21:04 ` [PATCH v2 00/21] blksnap - block devices snapshots module Mike Snitzer
2023-01-18 10:51   ` Hannes Reinecke
2023-01-24 11:34   ` Sergei Shtepa
2023-01-31 20:47     ` Mike Snitzer
2023-02-01  2:32       ` Mason Giles

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=Y5rwa6m3yqo40vz1@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergei.shtepa@veeam.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).