[lkml]   [2005]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] cifs: handle termination of cifs oplockd kernel thread
    > 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-30 18:21    [W:0.019 / U:19.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site