On Tue, Mar 14, 2023 at 08:00:21AM +0200, Amir Goldstein wrote: > On Tue, Mar 14, 2023 at 7:25 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > On Tue, Mar 14, 2023 at 07:11:56AM +0200, Amir Goldstein wrote: > > > On Tue, Mar 14, 2023 at 6:25 AM Catherine Hoang > > > <catherine.hoang@xxxxxxxxxx> wrote: > > > > > > > > Implement internal freeze/thaw functions and prevent other threads from changing > > > > the freeze level by adding a new SB_FREEZE_ECLUSIVE level. This is required to > > > > > > This looks troubling in several ways: > > > - Layering violation > > > - Duplication of subtle vfs code > > > > > > > prevent concurrent transactions while we are updating the uuid. > > > > > > > > > > Wouldn't it be easier to hold s_umount while updating the uuid? > > > > Why? Userspace holds an open file descriptor, the fs won't get > > unmounted. > > "Implement internal freeze/thaw functions and prevent other threads > from changing > the freeze level..." > > holding s_umount prevents changing freeze levels. > > The special thing about the frozen state is that userspace is allowed > to leave the fs frozen without holding any open fd, but because there > is no such requirement from SET_FSUUID I don't understand the need > for a new freeze level. Hm. I think you could be right, since we can certainly run transactions with s_umount held. I wonder if we're going to run into problems with the weird xlog things that fsuuid setting will want, but I guess we have lockdep on our side, right? ;) --D > Thanks, > Amir.
