public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Keith Busch <kbusch@kernel.org>,
	Conrad Meyer <conradmeyer@meta.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-mmc@vger.kernel.org, linux-block@vger.kernel.org
Subject: [PATCH 04/10] blk-lib: check for kill signal in ioctl BLKSECDISCARD
Date: Mon,  1 Jul 2024 18:51:14 +0200	[thread overview]
Message-ID: <20240701165219.1571322-5-hch@lst.de> (raw)
In-Reply-To: <20240701165219.1571322-1-hch@lst.de>

Secure Erase can access a significant capacity and take longer than the
user expected.  A user may change their mind about wanting to run that
command and attempt to kill the process and do something else with their
device. But since the task is uninterruptable, they have to wait for it
to finish, which could be many hours.

Open code blkdev_issue_secure_erase in the BLKSECDISCARD ioctl handler
and check for a fatal signal at each iteration so the user doesn't have
to wait for their regretted operation to complete naturally.

Heavily based on an earlier patch from Keith Busch.

Reported-by: Conrad Meyer <conradmeyer@meta.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/ioctl.c | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index f53121edb9a15f..45668a21cdb374 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -164,6 +164,9 @@ static int blk_ioctl_secure_erase(struct block_device *bdev, blk_mode_t mode,
 		void __user *argp)
 {
 	unsigned int bs_mask = bdev_logical_block_size(bdev) - 1;
+	struct bio *prev = NULL, *bio;
+	sector_t sector, nr_sects;
+	struct blk_plug plug;
 	uint64_t start, len;
 	uint64_t range[2];
 	int err;
@@ -187,11 +190,36 @@ static int blk_ioctl_secure_erase(struct block_device *bdev, blk_mode_t mode,
 	if (start + len > bdev_nr_bytes(bdev))
 		return -EINVAL;
 
+	sector = start >> SECTOR_SHIFT;
+	nr_sects = len >> SECTOR_SHIFT;
+
 	filemap_invalidate_lock(bdev->bd_mapping);
 	err = truncate_bdev_range(bdev, mode, start, start + len - 1);
-	if (!err)
-		err = blkdev_issue_secure_erase(bdev, start >> 9, len >> 9,
-						GFP_KERNEL);
+	if (err)
+		goto out_unlock;
+
+	blk_start_plug(&plug);
+	while (1) {
+		if (fatal_signal_pending(current)) {
+			if (prev)
+				bio_await_chain(prev);
+			err = -EINTR;
+			goto out_unplug;
+		}
+		bio = blk_alloc_secure_erase_bio(bdev, &sector, &nr_sects,
+				GFP_KERNEL);
+		if (!bio)
+			break;
+		prev = bio_chain_and_submit(prev, bio);
+	}
+	if (prev) {
+		err = submit_bio_wait(prev);
+		bio_put(prev);
+	}
+
+out_unplug:
+	blk_finish_plug(&plug);
+out_unlock:
 	filemap_invalidate_unlock(bdev->bd_mapping);
 	return err;
 }
-- 
2.43.0


  parent reply	other threads:[~2024-07-01 16:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-01 16:51 make secure erase and write zeroes ioctls interruptible as well Christoph Hellwig
2024-07-01 16:51 ` [PATCH 01/10] block: move secure erase checks into the ioctl handler Christoph Hellwig
2024-07-01 16:51 ` [PATCH 02/10] block: factor out a bio_secure_erase_limit helper Christoph Hellwig
2024-07-01 16:51 ` [PATCH 03/10] block: add a blk_alloc_secure_erase_bio helper Christoph Hellwig
2024-07-01 16:51 ` Christoph Hellwig [this message]
2024-07-01 16:51 ` [PATCH 05/10] block: factor out a blk_write_zeroes_limit helper Christoph Hellwig
2024-07-01 16:51 ` [PATCH 06/10] block: remove the LBA alignment check in __blkdev_issue_zeroout Christoph Hellwig
2024-07-01 16:51 ` [PATCH 07/10] block: move read-only and supported checks into (__)blkdev_issue_zeroout Christoph Hellwig
2024-07-01 16:51 ` [PATCH 08/10] block: refacto blkdev_issue_zeroout Christoph Hellwig
2024-07-01 16:51 ` [PATCH 09/10] block: limit the Write Zeroes to manually writing zeroes fallback Christoph Hellwig
2024-07-01 16:51 ` [PATCH 10/10] blk-lib: check for kill signal in ioctl BLKZEROOUT Christoph Hellwig
2024-07-05  4:03 ` make secure erase and write zeroes ioctls interruptible as well Martin K. Petersen
2024-07-05  6:45 ` Jens Axboe
2024-07-05  6:50   ` Christoph Hellwig
2024-07-05  7:03     ` Jens Axboe
2024-07-05 12:12   ` Christoph Hellwig
2024-07-05  6:53 ` (subset) " Jens Axboe

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=20240701165219.1571322-5-hch@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=conradmeyer@meta.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /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