From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>, Josef Bacik <josef@toxicpanda.com>,
Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Jan Kara <jack@suse.cz>, "Darrick J . Wong" <djwong@kernel.org>,
Ming Lei <ming.lei@redhat.com>,
Matteo Croce <mcroce@microsoft.com>,
linux-block@vger.kernel.org, nbd@other.debian.org
Subject: [PATCH 02/15] zram: cleanup reset_store
Date: Wed, 30 Mar 2022 07:29:04 +0200 [thread overview]
Message-ID: <20220330052917.2566582-3-hch@lst.de> (raw)
In-Reply-To: <20220330052917.2566582-1-hch@lst.de>
Use a local variable for the gendisk instead of the part0 block_device,
as the gendisk is what this function actually operates on.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
---
drivers/block/zram/zram_drv.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index e9474b02012de..fd83fad59beb1 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1786,7 +1786,7 @@ static ssize_t reset_store(struct device *dev,
int ret;
unsigned short do_reset;
struct zram *zram;
- struct block_device *bdev;
+ struct gendisk *disk;
ret = kstrtou16(buf, 10, &do_reset);
if (ret)
@@ -1796,26 +1796,26 @@ static ssize_t reset_store(struct device *dev,
return -EINVAL;
zram = dev_to_zram(dev);
- bdev = zram->disk->part0;
+ disk = zram->disk;
- mutex_lock(&bdev->bd_disk->open_mutex);
+ mutex_lock(&disk->open_mutex);
/* Do not reset an active device or claimed device */
- if (bdev->bd_openers || zram->claim) {
- mutex_unlock(&bdev->bd_disk->open_mutex);
+ if (disk->part0->bd_openers || zram->claim) {
+ mutex_unlock(&disk->open_mutex);
return -EBUSY;
}
/* From now on, anyone can't open /dev/zram[0-9] */
zram->claim = true;
- mutex_unlock(&bdev->bd_disk->open_mutex);
+ mutex_unlock(&disk->open_mutex);
/* Make sure all the pending I/O are finished */
- sync_blockdev(bdev);
+ sync_blockdev(disk->part0);
zram_reset_device(zram);
- mutex_lock(&bdev->bd_disk->open_mutex);
+ mutex_lock(&disk->open_mutex);
zram->claim = false;
- mutex_unlock(&bdev->bd_disk->open_mutex);
+ mutex_unlock(&disk->open_mutex);
return len;
}
--
2.30.2
next prev parent reply other threads:[~2022-03-30 5:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 5:29 yet another approach to fix the loop lock order inversions v6 Christoph Hellwig
2022-03-30 5:29 ` [PATCH 01/15] nbd: use the correct block_device in nbd_bdev_reset Christoph Hellwig
2022-04-18 12:54 ` Jens Axboe
2022-03-30 5:29 ` Christoph Hellwig [this message]
2022-03-30 5:29 ` [PATCH 03/15] zram: cleanup zram_remove Christoph Hellwig
2022-03-30 5:29 ` [PATCH 04/15] block: add a disk_openers helper Christoph Hellwig
2022-03-30 5:29 ` [PATCH 05/15] block: turn bdev->bd_openers into an atomic_t Christoph Hellwig
2022-03-30 5:29 ` [PATCH 06/15] loop: de-duplicate the idle worker freeing code Christoph Hellwig
2022-03-30 5:29 ` [PATCH 07/15] loop: initialize the worker tracking fields once Christoph Hellwig
2022-03-30 5:29 ` [PATCH 08/15] loop: remove the racy bd_inode->i_mapping->nrpages asserts Christoph Hellwig
2022-03-30 5:29 ` [PATCH 09/15] loop: don't freeze the queue in lo_release Christoph Hellwig
2022-03-30 5:29 ` [PATCH 10/15] loop: only freeze the queue in __loop_clr_fd when needed Christoph Hellwig
2022-03-30 5:29 ` [PATCH 11/15] loop: implement ->free_disk Christoph Hellwig
2022-03-30 5:29 ` [PATCH 12/15] loop: suppress uevents while reconfiguring the device Christoph Hellwig
2022-03-30 5:29 ` [PATCH 13/15] loop: avoid loop_validate_mutex/lo_mutex in ->release Christoph Hellwig
2022-03-30 5:29 ` [PATCH 14/15] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release Christoph Hellwig
2022-03-30 5:29 ` [PATCH 15/15] loop: don't destroy lo->workqueue in __loop_clr_fd Christoph Hellwig
2022-04-04 7:42 ` yet another approach to fix the loop lock order inversions v6 Christoph Hellwig
2022-04-04 9:39 ` Tetsuo Handa
2022-04-05 6:28 ` Christoph Hellwig
2022-04-05 6:38 ` Tetsuo Handa
2022-04-05 9:10 ` Jan Kara
2022-04-18 9:39 ` Tetsuo Handa
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=20220330052917.2566582-3-hch@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=mcroce@microsoft.com \
--cc=minchan@kernel.org \
--cc=ming.lei@redhat.com \
--cc=nbd@other.debian.org \
--cc=ngupta@vflare.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/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