Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iac594737:Fastmail
Date:   Wed, 7 Jun 2023 12:42:00 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block, loop: Increment diskseq when releasing a loop
 device
Message-ID: <ZICzXbJeLj56NRYB@itl-email>
References: <20230601222656.2062-1-demi@invisiblethingslab.com>
 <ZIA004HDuhoTQzY/@infradead.org>
 <ZICg2sxHQRRPW3Nc@itl-email>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="Lhc+hn0jVRR2V+8y"
Content-Disposition: inline
In-Reply-To: <ZICg2sxHQRRPW3Nc@itl-email>
Precedence: bulk


--Lhc+hn0jVRR2V+8y
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Jun 2023 12:42:00 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block, loop: Increment diskseq when releasing a loop
 device

On Wed, Jun 07, 2023 at 11:23:00AM -0400, Demi Marie Obenour wrote:
> > > --- a/drivers/block/loop.c
> > > +++ b/drivers/block/loop.c
> > > @@ -1205,6 +1205,12 @@ static void __loop_clr_fd(struct loop_device *=
lo, bool release)
> > >  	if (!part_shift)
> > >  		set_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
> > >  	mutex_lock(&lo->lo_mutex);
> > > +
> > > +	/*
> > > +	 * Increment the disk sequence number, so that userspace knows this
> > > +	 * device now points to something else.
> > > +	 */
> > > +	inc_diskseq(lo->lo_disk);
> >=20
> > And I'm not sure why we even need this.  __loop_clr_fd
> > already calls disk_force_media_change, which calls inc_diskseq.
> > Why do we need an extra increment?
>=20
> How does disk_force_media_change() call inc_diskseq()?  I don=E2=80=99t s=
ee any
> calls in the source code.  I=E2=80=99m going to use systemtap to see if t=
here is
> an indirect call chain.

Were you thinking of bdev_check_media_change()?  That can call
inc_diskseq() via this call chain:

  bdev_check_media_change()
    disk_clear_events()
      disk_check_events()
        inc_diskseq()

disk_force_media_change() does not call inc_diskseq(), and I checked
that calling losetup -D does not change the diskseq of a loop device.
=46rom what you have writte, I=E2=80=99m pretty sure that=E2=80=99s a bug in
disk_force_media_change(), though.  I=E2=80=99ll send a v3 that adds this c=
all.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--Lhc+hn0jVRR2V+8y
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmSAs10ACgkQsoi1X/+c
IsGbBBAAoZxDjSSs9J+siCWh0MMyGUEwddaQhnOqS6hH//JuLOHDb71mJVF51gZR
ayDHrJnYDhxsSpb02lxWKKPfo0plXSnTwb8gt2ZX+HUIXR+QteXUpfXzKi45ZwT7
p70ZnygsFNmn24ePKu5RS491F3n/Kz51PPdacIE429QBLi5YRAAlTTan4pOJRvRt
bgliY4CSe63mDrCJ4GMd7614e4mTPrsaJYbAAx5ri1xJBNy8pKjbyUMcSfR5VQnu
ujJgAXImHu3mzEeJlHKusofkCA43rWdhLsrZvrjArGXEXOcK7Qk4zkVUGh/dG7Ta
QxljW+MD+foQRsFmsrc+XMfIpPuWy/AigkYi7a+jINyzwfmNqfnWwuxW4Q3mQlhu
eJ7inplmVJ7xsPJKbRL/DcqiHvE+KgGU5GHuZPCwu7e9G+pkcEJ1kTqzHZrRTAJW
WXhLxBLajojgzKCrbTusEmLuodkVMZpqM1VPsSBeGjYwV+BvVlymK15DWtlxffC4
XdsQHu88yG8rdDe4TO7GgSWfNXDGuIQOtmHTsvrvLR/XVduEByxaXdsYj5k5JO/V
A7h0LAnLqTZo2+0tYqaFHHUjUHWua8edZYrdVvXTsNgkMfDol8/SGSSsbstvEbGz
8WGMKF+Qp8uA8T9fUDq95d6QDXwdg1E5NLawy7Yg9CfYScpy1Mg=
=AmeY
-----END PGP SIGNATURE-----

--Lhc+hn0jVRR2V+8y--