On Mon, Jul 14, 2025 at 12:27:37PM +0200, Christian Brauner wrote: > > My bad, it's calling back into freeze_super() function, so it's fine. > > You have to expose yourself to all the VFS handling and you must call > freeze_super() at some point. You can't just do freeze on your own. You > have roughly the following classes of freeze calls: > > (1) initiated from userspace > (1.1) initiated from the block layer => upcall into the filesystem > (1.2) initiated from the filesystem > (2) initiated from the kernel > (2.1) initiated from the filesystem > (2.2) suspend/hibernation > > All of that requires synchronization and you cannot do this without > going through the VFS layer's locking safely. At least not without > causing royal pain for yourself and the block and VFS layer. You weren't CCed on the initial patch https://lore.kernel.org/linux-btrfs/20250708132540.28285-1-dsterba@xxxxxxxx/ so you can see we're not avoiding VFS, freeze_super() is called. The problem I am solving is that we need to pass the information about freezing being started before freeze_super() is called, or alternatively by something that is set there before sb_wait_write() call. > > The remaining concern is just should we do this by using > > ->freeze_super() callback, or do the f2fs' way by poking into > > s_writer.frozen. > > > > I'd prefer the later one, as that's already exposed to filesystems and we do > > not need extra callback functions especially when it's not widely used. > > This would be simpler. You should probably add a helper that you can > share with gfs2 to sample the state instead of raw accesses to > s_writers->frozen. I find the latter a bit ugly and error prone if we > ever change this. I'd rather have it encapsulated in the VFS layer as > best as we can. I chose to use separate bit rather than using s_writers->frozen, which is what Qu prefers. I disgree with that on the API level as we probably should not do such direct check. A helper would be best, semantically teh same as the added filesystem bit.
