On 20.8.2012 9:36, Zdenek Bouska wrote: >>> VFS mount => overlayer FS mount => VFS stat on different FS file => >>> deadlock >> >> Can you be more specific? What are these 'overlayer' fs trying to do? >> > Ok, not a good term. Filesystem with it's data stored in other > filesystem. It needs to call VFS IN protocol from it own implementation > of VFS OUT protocol. For example it could unzip or decrypt files, log > operations with files or it could have it's encrypted/zipped data stored > in one big file.
There is something similar in use already: file_bd. You can mount an image located on another filesystem with it. The difference is that you don't use a specialized filesystem, but a specialized block device. It does not deadlock because file_bd only uses read() and write() after the device is created. The open() (and the accompanying VFS_OUT_LOOKUP) is done before the mount command. The solution with a global namespace lock traded flexibility for simplicity. When your fs implementation uses the VFS input interface (e.g. via libc wrappers) it always creates a possibility for a deadlock because it creates a loop and there may always be some locks taken or resources consumed along the codepaths that form the loop. The more operations this loop involves, the more likely it is that there will be a deadlock. We should probably change this behavior and remove this inflexibility as it is a potential security problem at the same time; if we want to have unprivileged file systems (or just privileged less than VFS), VFS needs to be able to gracefully survive someone's attempt to do crazy stuff. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
