From: Tejun Heo <tj@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
Minho Ban <mhban@samsung.com>,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: RFC: sort out get_gendisk abuses
Date: Wed, 30 Sep 2020 12:17:42 -0400 [thread overview]
Message-ID: <20200930161742.GF4441@mtj.duckdns.org> (raw)
In-Reply-To: <20200925161447.1486883-1-hch@lst.de>
Hello, Christoph.
On Fri, Sep 25, 2020 at 06:14:45PM +0200, Christoph Hellwig wrote:
> this series tries to remove two abuses of the get_gendisk API.
> The first one is fairly straigt forward and switched the blk-cgroup
> configuration API to properly open the block device, but I'd love to see
> it reviewed and tested by the cgroup maintainers, as I don't really know
> how this code is actually used.
I'm a bit worried that requiring fully opening the device for configuration
can lead to surprising behaviors. A now-unlikely but still possible case
would be trying to configure IO parameters for a device w/ removeable media.
All that the user is trying to do is configuring a bunch of parameters but
the kernel would try to spin up the media and fail configuration and so on.
The use case of needing to access the associated data structures without
fully activating the IO device seems valid to me. Whether that interface is
blkdev_get() or something better abstracted, I don't really care.
Thanks.
--
tejun
prev parent reply other threads:[~2020-09-30 16:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 16:14 RFC: sort out get_gendisk abuses Christoph Hellwig
2020-09-25 16:14 ` [PATCH 1/2] blk-cgroup: stop abusing get_gendisk Christoph Hellwig
2020-09-25 16:14 ` [PATCH 2/2] PM/hibernate: remove the bogus call to get_gendisk in software_resume Christoph Hellwig
2020-09-25 18:38 ` Pavel Machek
2020-09-26 14:05 ` Christoph Hellwig
2020-09-30 15:45 ` Rafael J. Wysocki
2020-10-02 6:50 ` Christoph Hellwig
2020-10-02 14:11 ` Rafael J. Wysocki
2020-09-30 16:17 ` Tejun Heo [this message]
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=20200930161742.GF4441@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=hch@lst.de \
--cc=len.brown@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mhban@samsung.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
/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).