On Tue 29-03-22 08:39:21, Christoph Hellwig wrote: > On Mon, Mar 28, 2022 at 10:30:45AM +0200, Jan Kara wrote: > > On Fri 25-03-22 17:23:31, Christoph Hellwig wrote: > > > On Fri, Mar 25, 2022 at 07:54:15PM +0900, Tetsuo Handa wrote: > > > > > But for now I'd really prefer to stop moving the goalpost further and > > > > > further. > > > > > > > > Then, why not kill this code? > > > > > > I think we should eventually do that, and I've indeed tested a patch > > > that is only cosmetically different. I wasn't really convinced we > > > should do it in this series, but if there is consensus that we should > > > do it now I can respin the series with a patch like this included. > > > > I'd defer it to a separate patchset. Because as much as the change to > > disallow LOOP_CLR_FD ioctl for used loop device makes sense, I'm not sure > > there isn't some framework using loop devices somewhere which relies on > > this just getting magically translated to setting LO_AUTOCLEAR flag. So IMO > > this has a big potential of userspace visible regression and as such I'd > > prefer doing it separately from the bugfixes. > > At least my idea would not be to disallow LOOP_CLR_FD on a used block > devices as that would go back to the udev problems before Dave turned > it into a magic LO_AUTOCLEAR. But to remove the lo_refcnt check > 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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
