On Mon, 05 Mar 2012 18:53:27 +0400 Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> wrote: > 05.03.2012 18:39, Jeff Layton пишет: > > > > Ok, I've started looking at the existing examples to try and ease the > > eventual containerization of this. Am I correct that the existing > > blocklayout pipe containerization is not yet complete? > > > > AIUI, you have a rpc_pipe per nfs_net struct, and those structs are > > allocated on a per-net basis. bl_pipe_downcall does this however: > > > > if (copy_from_user(&bl_mount_reply, src, mlen) != 0) > > return -EFAULT; > > > > ...but bl_mount_reply is global: > > > > static struct bl_dev_msg bl_mount_reply; > > > > So, if you're getting downcalls in two different network namespaces at > > the same time this could end up corrupt. It seems like bl_mount_reply > > needs to be part of nfs_net as well. > > Thanks for this catch, Jeff! > I need to fix this. > > > > > When you get a downcall, you have a filp pointer. Is there any way to > > determine the "correct" nfs_net object for a particular filp? > > > > Yes, sure. > This nfs_net object will be, obviously, in the same network namespace, as PipeFS > superblock. Network namespace is stored on PipeFS sb->s_fs_info. > IOW, code below should works: > > struct nfs_net *nn = net_generic(file->f_dentry->d_sb->s_fs_info, nfs_net_id); > Ok, I'm going to have to do something similar for the cld upcall eventually. We'll need a per-ns list of upcalls in flight, xid counter and spinlock. What may be best is to go ahead and introduce a nfsd_net struct as a per-net object start putting stuff inside it. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
