Messages in this thread | | | Subject | Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread | From | Miklos Szeredi <> | Date | Sat, 30 Apr 2005 18:16:52 +0200 |
| |
> 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/
| |