On Thu, Aug 28, 2025 at 8:01 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Thu, Aug 28, 2025 at 04:08:19PM +0200, Miklos Szeredi wrote: > > On Wed, 27 Aug 2025 at 21:12, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > > Well sync() will poke all the fuse filesystems, right? > > > > Only those with writeback_cache enabled. But yeah, apparently this > > was overlooked when dealing with "don't allow DoS-ing sync(2)". > > > > Can't see a good way out of this. > > I wonder, is it possible to shift a fuse_simple_request to behave like a > fuse_simple_background request? For certain DOS-happy requests, one > could use wait_event_interruptible_timeout(&req->waitq...) with a really > high timeout. > > If the wait times out, we shift the completion to asynchronous and > return -ETIMEDOUT to the (blocked) caller. That would allow the system > to make progress though you'd probably have to take some drastic action > if the fuse server sends back a failure (e.g. setting FUSE_I_BAD). > > (The problem with timeouts is that I tried setting a 60s timeout on > fuse2fs and discovered that certain horrid fstests actually create > monster files that take 45min to FUSE_RELEASE and so I don't know what a > reasonable timeout is...) Why not just send the setattr request in fuse_write_inode() as a background request instead of first sending it synchronously with a timeout? for the sync() case, the only DoS path is (as Miklos pointed out to me in his earlier comment) the sync_inodes_one_sb() -> fuse_write_inode(). But the only thing fuse_write_inode() does is call fuse_flush_times() to send the inode i_mtime to the server. Is this i_mtime info even that important? It seems fine to me to have that relayed always as a background request. Thanks, Joanne > > --D > > > Thanks, > > Miklos
