Re: [PATCH 12/13] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release
- To: Christoph Hellwig <firstname.lastname@example.org>
- Cc: Jan Kara <email@example.com>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, Dave Chinner <firstname.lastname@example.org>, Jens Axboe <email@example.com>, Josef Bacik <firstname.lastname@example.org>, Minchan Kim <email@example.com>, Nitin Gupta <firstname.lastname@example.org>, "Darrick J . Wong" <email@example.com>, Ming Lei <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
- Subject: Re: [PATCH 12/13] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release
- From: Jan Kara <email@example.com>
- Date: Wed, 30 Mar 2022 09:58:09 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <[🔎] 20220329131427.GA1848@lst.de>
- References: <[🔎] email@example.com> <[🔎] firstname.lastname@example.org> <[🔎] 96a4e2e7-e16e-7e89-255d-8aa29ffca68b@I-love.SAKURA.ne.jp> <[🔎] 20220324172335.GA28299@lst.de> <[🔎] 0b47dbee-ce17-7502-6bf3-fad939f89bb7@I-love.SAKURA.ne.jp> <[🔎] 20220325162331.GA16355@lst.de> <[🔎] email@example.com> <[🔎] 20220329063921.GA19778@lst.de> <[🔎] firstname.lastname@example.org> <[🔎] 20220329131427.GA1848@lst.de>
On Tue 29-03-22 15:14:27, Christoph Hellwig wrote:
> On Tue, Mar 29, 2022 at 11:42:03AM +0200, Jan Kara wrote:
> > > entirely, as loop_clr_fd now is safe against concurrent users - it
> > > has to anyway as there can be other users even without an open.
> > Ah, OK, so you'd always set LO_AUTOCLEAR and leave cleanup to happen
> > from lo_release()? That makes sense to me.
> No, my idea was to never set LO_AUTOCLEAR. We have a frozen queue and
> all protections in place to make clearing the file perfectly safe.
> In fact the change_fd case also allows this.
I see, thanks for explanation. But then there's the risk of userspace
regressions if someone relies on the current behavior that LOOP_CLR_FD
ioctl does only delayed teardown of the device if someone is using it.
Personally I don't think the risk of regression is worth the benefit of the
cleanup but maybe it's worth trying. At least I know that for loop device
handling inside mount(8) (which plays tricks with reusing existing bound
loop devices), this change should be safe.
Jan Kara <email@example.com>
SUSE Labs, CR