On Tue, Jan 26, 2021 at 05:18:29PM +0100, Jan Kara wrote:

On Tue 26-01-21 13:34:06, Christoph Hellwig wrote:

quoted

On Tue, Jan 26, 2021 at 02:17:52PM +0100, Jan Kara wrote:

quoted

Well, I don't think that "wait until unfrozen" is that strange e.g. for
Q_SETQUOTA - it behaves like setxattr() or any other filesystem
modification operation. And IMO it is desirable that filesystem freezing is
transparent for operations like these. For stuff like Q_QUOTAON, I agree
that returning EBUSY makes sense but then I'm not convinced it's really
simpler or more useful behavior...

If we want it to behave like other syscalls we'll just need to throw in
a mnt_want_write/mnt_drop_write pair.  Than it behaves exactly like other
syscalls.

Right, we could do that. I'd just note that the "wait until unfrozen" and
holding of sb->s_umount semaphore is equivalent to
mnt_want_write/mnt_drop_write pair. But I agree
mnt_want_write/mnt_drop_write is easier to understand and there's no reason
not to use it. So I'm for that simplification in the new syscall.

Due to the user_path_at() to the mountpoint the fs won't go away, so I
guess for non-exclusive, non-write quota command I don't need any
additional locking. For non-exclusive, write commands I'll need a
mnt_want_write/mnt_drop_write pair. What about the exclusive, write
commands (Q_QUOTAON/Q_QUOTAOFF)?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |