Re: [PATCH 13/14] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release
- To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
- Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>, Josef Bacik <josef@toxicpanda.com>, Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>, 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: Re: [PATCH 13/14] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release
- From: Christoph Hellwig <hch@lst.de>
- Date: Tue, 29 Mar 2022 15:25:02 +0200
- Message-id: <[🔎] 20220329132502.GA2024@lst.de>
- In-reply-to: <[🔎] 20220329065234.GA20006@lst.de>
- References: <[🔎] 20220325063929.1773899-1-hch@lst.de> <[🔎] 20220325063929.1773899-14-hch@lst.de> <[🔎] 03628e13-ca56-4ed0-da5a-ee698c83f48d@I-love.SAKURA.ne.jp> <[🔎] 20220329065234.GA20006@lst.de>
Thinking a bit more, I really don't think the existing any refcount
check protects us against a different tread modififying the backing
file. When a process has a file descriptor to a loop device open
and is multithreaded (or forks) we can still have multiple threads
manipulating the loop state.
That being said I do not think we really need that refcount check
at all - once loop_clr_fd set lo->lo_state to Lo_rundown under the
global lock we know that loop_validate_file will error out on it
due to the lo_state != Lo_bound check.
Reply to: