On Feb 24, 2012, at 3:03 AM, Stanislav Kinsbursky wrote: > 23.02.2012 21:48, Fred Isaman пишет: >> This needs to be looked at closely by someone more familiar with the >> pipe code. >> >> It fixes an issue with the current nfs_for_next branch which causes a >> chain of oopses on umount every time if sufficient CONFIG_* debug >> options are set. >> >> A git-bisect shows that the problem was introduced by >> commit c239d83b SUNRPC: split SUNPRC PipeFS dentry and private pipe data creation >> > > > > NAK, the whole patch idea is bad. > Currently, pipe data is created during NFS kernel part initialization, when PipeFS inode is created only on PipeFS mount and destroyed on PipeFS umount. And this creation/destruction has to have nothing with kernel pipes at all - these inodes are just a kind of front-end to kernel data. > Please, provide exact CONFIG_* debug options for investigation. > > I've attached my .config, which is run on a vmware fusion guest. I was testing on a fresh install of Fedora 16 with Trond's nfs-for-next kernel. Just doing a nfs4.1 mount/umount against any server with no intervening io causes the oops. Below are some notes I took while investigating: with the recent nfs-for-next code, umount always oopses (if CONFIG_PROVE_LOCKING is set?). (Note this is using the old idmapper, which is the default Fedora 16 configuration) This behavior starts with commit e6499c6f NFS: Fall back on old idmapper if request_key() fails, which removes the CONFIG_NFS_USE_NEW_IDMAPPER option. Prior to this, it works correctly if the option is set, but has the same bad behavior if clear. commit c239d83b SUNRPC: split SUNPRC PipeFS dentry and private pipe data creation is the commit that actually introduces the bad behavior. Fred
Attachment:
FUSION64-FED16
Description: Binary data
