Re: [PATCH 12/13] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release
- To: Christoph Hellwig <hch@lst.de>
- Cc: Jan Kara <jack@suse.cz>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, Dave Chinner <david@fromorbit.com>, Jens Axboe <axboe@kernel.dk>, Josef Bacik <josef@toxicpanda.com>, Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>, "Darrick J . Wong" <djwong@kernel.org>, Ming Lei <ming.lei@redhat.com>, linux-block@vger.kernel.org, nbd@other.debian.org
- Subject: Re: [PATCH 12/13] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release
- From: Jan Kara <jack@suse.cz>
- Date: Wed, 30 Mar 2022 09:58:09 +0200
- Message-id: <[🔎] 20220330075809.f7676hejthuwcyk6@quack3.lan>
- In-reply-to: <[🔎] 20220329131427.GA1848@lst.de>
- References: <[🔎] 20220324075119.1556334-13-hch@lst.de> <[🔎] 20220324141321.pqesnshaswwk3svk@quack3.lan> <[🔎] 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> <[🔎] 20220328083045.ryoh7rbhauxgezgn@quack3.lan> <[🔎] 20220329063921.GA19778@lst.de> <[🔎] 20220329094203.zkgkqtumix7nygs2@quack3.lan> <[🔎] 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.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
Reply to: