From: Christoph Hellwig <hch@infradead.org>
To: Michal Suchanek <msuchanek@suse.de>
Cc: linux-scsi@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Jens Axboe <axboe@kernel.dk>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Eric Biggers <ebiggers@google.com>,
"J. Bruce Fields" <bfields@redhat.com>,
Benjamin Coddington <bcodding@redhat.com>,
Hannes Reinecke <hare@suse.com>, Omar Sandoval <osandov@fb.com>,
Ming Lei <ming.lei@redhat.com>,
Damien Le Moal <damien.lemoal@wdc.com>,
Bart Van Assche <bvanassche@acm.org>, Tejun Heo <tj@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 6/8] bdev: add open_finish.
Date: Wed, 23 Oct 2019 19:22:32 -0700 [thread overview]
Message-ID: <20191024022232.GB11485@infradead.org> (raw)
In-Reply-To: <ea2652294651cbc8549736728c650d16d2fe1808.1571834862.git.msuchanek@suse.de>
On Wed, Oct 23, 2019 at 02:52:45PM +0200, Michal Suchanek wrote:
> Opening a block device may require a long operation such as waiting for
> the cdrom tray to close. Performing this operation with locks held locks
> out other attempts to open the device. These processes waiting to open
> the device are not killable.
>
> To avoid this issue and still be able to perform time-consuming checks
> at open() time the block device driver can provide open_finish(). If it
> does opening the device proceeds even when an error is returned from
> open(), bd_mutex is released and open_finish() is called. If
> open_finish() succeeds the device is now open, if it fails release() is
> called.
>
> When -ERESTARTSYS is returned from open() blkdev_get may loop without
> calling open_finish(). On -ERESTARTSYS open_finish() is not called.
>
> Move a ret = 0 assignment up in the if/else branching to avoid returning
> -ENXIO. Previously the return value was ignored on the unhandled branch.
This just doesn't make much sense. There is no point in messing up
the block API for ugly workarounds like that.
next prev parent reply other threads:[~2019-10-24 2:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 12:52 [PATCH v2 0/8] Fix cdrom autoclose Michal Suchanek
2019-10-23 12:52 ` [PATCH v2 1/8] cdrom: add poll_event_interruptible Michal Suchanek
2019-10-23 12:52 ` [PATCH v2 2/8] cdrom: factor out common open_for_* code Michal Suchanek
2019-10-24 2:19 ` Christoph Hellwig
2019-10-24 8:50 ` Michal Suchánek
2019-10-25 2:39 ` Christoph Hellwig
2019-10-25 10:42 ` Michal Suchánek
2019-10-26 6:46 ` Finn Thain
2019-10-24 13:23 ` Matthew Wilcox
2019-10-25 2:38 ` Christoph Hellwig
2019-10-23 12:52 ` [PATCH v2 3/8] cdrom: wait for the tray to close Michal Suchanek
2019-10-23 12:52 ` [PATCH v2 4/8] cdrom: separate autoclose into an IOCTL Michal Suchanek
2019-10-23 12:52 ` [PATCH v2 5/8] docs: cdrom: Add autoclose IOCTL Michal Suchanek
2019-10-23 12:52 ` [PATCH v2 6/8] bdev: add open_finish Michal Suchanek
2019-10-24 2:22 ` Christoph Hellwig [this message]
2019-10-24 8:55 ` Michal Suchánek
2019-10-24 13:12 ` Matthew Wilcox
2019-10-24 13:19 ` Michal Suchánek
2019-11-21 10:15 ` Michal Suchánek
2019-10-23 12:52 ` [PATCH v2 7/8] scsi: sr: workaround VMware ESXi cdrom emulation bug Michal Suchanek
2019-10-23 14:13 ` Hannes Reinecke
2019-10-23 16:23 ` Michal Suchánek
2019-10-23 21:44 ` Ewan D. Milne
2019-10-24 5:46 ` Hannes Reinecke
2019-10-24 8:56 ` Michal Suchánek
2019-10-24 9:41 ` Hannes Reinecke
2019-10-24 10:11 ` Michal Suchánek
2019-10-24 2:23 ` Christoph Hellwig
2019-10-24 8:53 ` Michal Suchánek
2019-11-21 15:21 ` Michal Suchánek
2019-10-23 12:52 ` [PATCH v2 8/8] scsi: sr: wait for the medium to become ready Michal Suchanek
2019-10-24 2:24 ` Christoph Hellwig
2019-10-24 8:51 ` Michal Suchánek
2019-10-24 13:14 ` Matthew Wilcox
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=20191024022232.GB11485@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=bcodding@redhat.com \
--cc=bfields@redhat.com \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=damien.lemoal@wdc.com \
--cc=ebiggers@google.com \
--cc=hare@suse.com \
--cc=jejb@linux.ibm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mchehab+samsung@kernel.org \
--cc=ming.lei@redhat.com \
--cc=msuchanek@suse.de \
--cc=osandov@fb.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).