From: Christoph Hellwig <hch@lst.de>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.cz>,
linux-block@vger.kernel.org, Ming Lei <ming.lei@redhat.com>
Subject: Re: [PATCH v3 1/5] task_work: export task_work_add()
Date: Wed, 26 Jan 2022 06:21:59 +0100 [thread overview]
Message-ID: <20220126052159.GA20838@lst.de> (raw)
In-Reply-To: <ec15d9ef-a659-e4f0-fc3f-c75acaa0be2a@I-love.SAKURA.ne.jp>
On Wed, Jan 26, 2022 at 08:47:17AM +0900, Tetsuo Handa wrote:
> > As far as I can tell we do not need the freeze at all for given that
> > by the time release is called I/O is quiesced.
>
> Why? lo_release() is called when close() is called. But (periodically-scheduled
> or triggered-on-demand) writeback of previously executed buffered write() calls
> can start while lo_release() or __loop_clr_fd() is running. Then, why not to
> wait for I/O requests to complete?
Let's refine my wording, the above should be "... by the time the final
lo_release is called". blkdev_put_whole ensures all writeback has finished
and all buffers are gone by writing all data back and waiting for it and then
truncating the pages from blkdev_flush_mapping.
> Isn't that the reason of
>
> } else if (lo->lo_state == Lo_bound) {
> /*
> * Otherwise keep thread (if running) and config,
> * but flush possible ongoing bios in thread.
> */
> blk_mq_freeze_queue(lo->lo_queue);
> blk_mq_unfreeze_queue(lo->lo_queue);
> }
>
> path in lo_release() being there?
This looks completely spurious to me. Adding Ming who added it.
next prev parent reply other threads:[~2022-01-26 5:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-21 11:40 [PATCH v3 1/5] task_work: export task_work_add() Tetsuo Handa
2022-01-21 11:40 ` [PATCH v3 2/5] loop: revert "make autoclear operation asynchronous" Tetsuo Handa
2022-01-21 11:40 ` [PATCH v3 3/5] loop: don't hold lo->lo_mutex from lo_open() Tetsuo Handa
2022-01-21 11:40 ` [PATCH v3 4/5] loop: don't hold lo->lo_mutex from lo_release() Tetsuo Handa
2022-01-21 11:40 ` [PATCH v3 5/5] loop: add workaround for racy loop device reuse logic in /bin/mount Tetsuo Handa
2022-01-25 15:47 ` [PATCH v3 1/5] task_work: export task_work_add() Christoph Hellwig
2022-01-25 23:47 ` Tetsuo Handa
2022-01-26 5:21 ` Christoph Hellwig [this message]
2022-01-26 7:18 ` Ming Lei
2022-01-26 10:27 ` Tetsuo Handa
2022-01-26 13:11 ` Jan Kara
2022-01-26 13:35 ` Tetsuo Handa
2022-01-25 21:37 ` Darrick J. Wong
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=20220126052159.GA20838@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.