Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread

[Miklos Szeredi <miklos@szeredi.hu>]

> Don't see how FUSE is that much safer, if you allocate kernel memory
> at all you eventually can create DoS, and you can not do a
> filesystem without allocating some kernel memory, but it does not
> seem that easy to do intentionally.

Allocating kernel memory is usually not a problem, when it's
associated with some object, whose number is already limited by the
kernel.  These are: cache entries (inode, dentry), file pointers
(limited in various ways), or super blocks (should be limited in case
of user mounts).

The big problem is the page cache, because that is not limited.  The
user can mmap huge amounts of memory, dirty them, and then when the
machine runs out of memory, and writeback kicks in, it may already be
too late.

This problem can be demonstrated with _any_ network filesystem that
supports shared writable mapping, and is mounted from the local
machine.  One exception is CODA, because it uses disk files as file
backing, and so does not have problems with writeback.

FUSE solves the problem by simply not allowing shared writable
mapping.  It's a _very_ hard thing to solve otherwise.  CIFS, smbfs,
etc, can do the same for unprivileged mounts, or untrusted servers.

> At least for the CIFS case you can turn off the page cache for
> inode data on a per mount basis (with the forcedirectio mount flag)
> if you worry about the server intentionally holding up writes.

That's sounds like a solution to this problem.

> Unless the write is past end of file, writes are timed out
> reasonably quickly anyway, and end up killing the session, which
> depending on the setting of the hard/soft flag probably should
> result in a page fault.

A timeout is also OK, but you should be careful, that the page under
writeback does get freed after the timeout.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/