2007/218 caller_context_t in all VOPs CONTEXT This is one of several related fast-tracks describing VFS changes that were spun off of the CIFS Service (PSARC 2006/715) case. Although each of these changes are part of the bigger picture, they have been broken down into smaller pieces so each gets the attention it deserves. It must be noted that several of these fast-tracks will describe changes to the signatures of vnode operations (VOPs). In some cases, these fast-tracks will describe multiple changes to the same VOPs. The project team intends to put all of these changes into ON in a single putback. INTRODUCTION The following proposes to add an additional parameter, a pointer to a caller_context_t structure, to all vnode operations (VOPs) that do not already have it. This will allow caller information to be passed to FEM monitors on all VOPs. Currently, 6 of them already pass a caller_context_t pointer: VOP_READ, VOP_WRITE, VOP_SETATTR, VOP_RWLOCK, VOP_RWUNLOCK, and VOP_SPACE. This change modifies the remaining 38 VOPs as well as their corresponding "fop" routines and FEM-related routines. Minor binding is requested for this change. OPLOCK/DELEGATION COORDINATION The NFSv4 server has the ability to "delegate" control of a file to one (in the case of a write delegation) or more (in the case of a read delegation) NFSv4 clients. This feature significantly cuts down on over-the-wire traffic and can improve client performance. In order to manage delegations in the face of non-NFS access (e.g. local or CIFS access), the the NFS server installs FEM monitors to recall delegations when a conflicting operation occurs. The CIFS server has a similar feature where it can grant an "oplock" to one or more clients. As with NFS, the CIFS server will need to detect conflicting operations so that it can "break" (recall) the oplock before the conflicting operation is allowed to continue. The CIFS server will also install FEM monitors on operations so that it can detect conflicting operations and break any oplocks. Monitors can be placed on any vnode operation but often need information from the caller, such as the caller's identity, to work properly. For example, the NFSv4 server adds a set of delegation monitors on to the conflicting vnode operations (e.g., VOP_READ and VOP_WRITE) but action is needed only when a non-NFS caller attempts to access the delegated file. The monitor makes that determination by checking the caller's ID in the caller_context field passed in the vnode operation. Today, only a subset of the vnode operations pass the pointer to the caller_context structure as an argument. The CIFS server requires additional vnode operations, such as VOP_OPEN, to pass a pointer to caller_context. Experience from the NFSv4 Delegation-On-By-Default project shows that it is difficult to determine the minimal set of operations requiring monitors a priori. Given this experience, this project proposes to add caller_context to all vnode operations and all corresponding FEM-related operations that don't currently pass it. WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? The only change to file systems is a signature change for the affected vnode operations. There is no behavioral changes needed. Rich Brown has already given a "heads-up" to Sun's contacts for unbundled file system developers (internal and external) that there will be signature changes. Those contacts will be given a full accounting of the changes once they've been completed. Note that Solaris Nevada now performs strong type-checking on vnode/FEM operations. This means that the compilers will inform the file system developers of the signature discrepancy in their code. All of the ON file systems will be updated with this change. Related cases: PSARC 2002/696 (added caller_context to VOP_READ, VOP_WRITE and friends) PSARC 2004/172 (added caller_context to VOP_SPACE, VOP_SETATTR, VOP_RWLOCK, VOP_RWUNLOCK and friends) PSARC/2007/124 Strong Type-Checking for VFS Operations Related Contracts PSARC 2001/599 (FS related interfaces for SAM-QFS) PSARC 2004/177 (FS related interfaces for Sun Cluster) EXPORTED INTERFACES: |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Contracted | | VOP_OPEN, fop_open, |Consolidation |This | Add new parameter: VOP_CLOSE, fop_close, |Private |Document | caller_context_t *ct VOP_IOCTL, fop_ioctl, | | | VOP_SETFL, fop_setfl, | | | VOP_GETATTR, | | | fop_getattr, | | | VOP_ACCESS, fop_access, | | | VOP_LOOKUP, fop_lookup, | | | VOP_CREATE, fop_create, | | | VOP_REMOVE, fop_remove, | | | VOP_LINK, fop_link, | | | VOP_RENAME, fop_rename, | | | VOP_MKDIR, fop_mkdir, | | | VOP_RMDIR, fop_rmdir, | | | VOP_READDIR, | | | fop_readdir, | | | VOP_SYMLINK, | | | fop_symlink, | | | VOP_READLINK, | | | fop_readlink, | | | VOP_FSYNC, fop_fsync, | | | VOP_INACTIVE, | | | fop_inactive, | | | VOP_FID, fop_fid, | | | VOP_SEEK, fop_seeks, | | | VOP_CMP, fop_cmp, | | | VOP_FRLOCK, fop_frlock, | | | VOP_REALVP, fop_realvp, | | | VOP_GETPAGE, | | | fop_getpage, | | | VOP_PUTPAGE, | | | fop_putpage, | | | VOP_MAP, fop_map, | | | VOP_ADDMAP, fop_addmap, | | | VOP_DELMAP, fop_delmap, | | | VOP_POLL, fop_poll, | | | VOP_DUMP, fop_dump, | | | VOP_PATHCONF, | | | fop_pathconf, | | | VOP_PAGEIO, fop_pageio, | | | VOP_DUMPCTL, | | | fop_dumpctl, | | | VOP_DISPOSE, | | | fop_dispose, | | | VOP_GETSECATTR, | | | fop_getsecattr, | | | VOP_SETSECATTR, | | | fop_setsecattr, | | | VOP_SHRLOCK, | | | fop_shrlock, | | | VOP_VNEVENT, | | | fop_vnevent | | | | | | vnext_open, | | | vnext_close, | | | vnext_ioctl, | | | vnext_setfl, | | | vnext_getattr, | | | vnext_access, | | | vnext_lookup, | | | vnext_create, | | | vnext_remove, | | | vnext_link, | | | vnext_rename, | | | vnext_mkdir, | | | vnext_rmdir, | | | vnext_readdir, | | | vnext_symlink, | | | vnext_readlink, | | | vnext_fsync, | | | vnext_inactive, | | | vnext_fid, | | | vnext_seek, | | | vnext_cmp, | | | vnext_frlock, | | | vnext_realvp, | | | vnext_getpage, | | | vnext_putpage, | | | vnext_map, | | | vnext_addmap, | | | vnext_delmap, | | | vnext_poll, | | | vnext_dump, | | | vnext_pathconf, | | | vnext_pageio, | | | vnext_dumpctl, | | | vnext_dispose, | | | vnext_setsecattr, | | | vnext_getsecattr, | | | vnext_shrlock, | | | vnext_vnevent | | | This is an addendum to PSARC/2007/218 (caller_context_t in all VOPs). PSARC/2004/170 introduced a set of support routines to be used by file systems to invoke VOP_VNEVENT() with the appropriate arguments. Since VOP_VNEVENT() will be passing a caller_context parameter then the routines described in PSARC 2004/170 also need to pass caller_context. The new signatures are: int fs_vnevent_support(vnode_t *vp, vnevent_t vnevent, caller_context_t *ct) int fs_vnevent_nosupport(vnode_t *vp, vnevent_t vnevent, caller_context_t *ct) int vnevent_support(vnode_t *vp, caller_context_t *ct); void vnevent_rename_src(vnode_t *vp, caller_context_t *ct); void vnevent_rename_dest(vnode_t *vp, caller_context_t *ct); void vnevent_remove(vnode_t *vp, caller_context_t *ct); void vnevent_rmdir(vnode_t *vp, caller_context_t *ct); This does not change the behavior or the use of these routines, only the signatures so that caller_context can be passed to VOP_VNEVENT(). |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Contracted | | fs_vnevent_support() |Consolidation |This | Add new parameter: fs_vnevent_nosupport() |Private |Document | caller_context_t *ct vnevent_support() | | | vnevent_rename_src() | | | vnevent_rename_dest() | | | vnevent_remove() | | | vnevent_rmdir() | | |