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

[Steve French]

Miklos Szeredi wrote:

> > > - network/userspace filesystems should be fine aswell
> > >      
> > They should, but again I wonder if NFS with all it's complexity is
> > being careful enough with what it accepts from the server.
> >    
That is the fun of trying to get our network filesystems up to the 20th 
century.  There is
at lot more work that has to be done here, but it is gradually 
improving.  At least for cifs
but probably for NFSv4 (and possibly AFS) it is possible for the client 
to validate that the
server is who it says it is, and both NFSv4 (actually the newer NFS RPC) 
and CIFS of course
allow packet signing which helps, not sure if AFS allows packet 
signing.   There does
need to be even more testing in one area though - selective packet 
corruption testing
(which can be done by temporarily modifying the server to inject random 
invalid packet
information on a subset of fields every thousand packets or so) since 
the biggest danger
in network filesystems is the huge variety of servers with different 
server bugs that you have
to be able to workaround.  Working around server bugs is a huge problem with
the client side of networking code.

> > I take that back.  Any filesystem using page cache and allowing shared
> > writable mapping is currently unsafe because of OOM deadlock if
> > mounted from local machine, or simply DoS against client by delaying
> > writeback.
> >
> > So other than FUSE, what's left as safe?
> >
> > Miklos
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.   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. 
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.

There is one remaining issue with mount and umount - the user space 
utilities.   By the way who maintains
them these days?   Although the mount utilities allow filesystem 
specific mount and umount helpers
to be placed in /sbin and automatically executed for the matching 
filesystem type, there are a few functions
that belong in common code - in a system library which today have to be 
implemented in every helper
function and of course are implemented in different ways in different 
distros and
different tools with possibility of corruption of the /etc/mtab.   It 
may be that the file /etc/mtab
does not matter and that it needs to go away and everyone needs to look 
at /proc/mounts instead, but
in the meantime /etc/mtab can easily get out of sync with the actual 
list of mounts, although that
usuallly does not prevent unmount from working it may be confusing.   
The basic problem is that the
"lock the mtab / add a new line to it / unlock" is not available in an 
exported function (alternatively if
lock and unlock mtab functions were exported that would help) and 
similarly with umount.there
is no "safely remove the matching line from mtab" -  Looking at the 
mount utils and various mount helper
functions it looks like you can not make any assumptions about the name 
of the lock file used to protect
mtab (I am not even sure that you can guarantee that /etc/mtab is a 
file, or even a symlink).  
the lock file used to lock the mtab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/