DTrace NFS v3 Provider [PSARC/2008/050 FastTrack timeout 01/24/2008]
On Jan 24, 2008, at 8:10 PM, Adam Leventhal wrote:
>
> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>DTrace NFS v3 Provider
> 1.2. Name of Document Author/Supplier:
>Author: Adam Leventhal
> 1.3 Date of This Document:
> 24 January, 2008
> 4. Technical Description
> The following specification describes the NFS v3 provider for
> DTrace. It has
> been reviewed and approved by the DTrace community; the PSARC case is
> closed approved automatic to record the interface. The stability is
> Committed
> and the binding is Patch.
>
> ---8<---
>
> NFS v3 Provider
>
> All NFS operation probes have the first argument in common:
>
> args[0] conninfo_t *socket connection information
>
> The conninfo_t structure is already used by the iSCSI target
> provider (iscsi)
> and the NFS v4 provider (nfsv4), and is intended for use by all
> providers
> related to a higher level protocol (e.g. iscsi, nfs, http, ftp).
>
> typedef struct conninfo {
> string ci_local;/* local host address */
> string ci_remote; /* remote host address */
> string ci_protocol; /* protocol (ipv4, ipv6, etc) */
> } conninfo_t;
>
>
> Operation probes have their second argument in common:
>
> args[1] nfsv3opinfo_t * NFS v3 operation properties
>
> typedef struct nfsv3opinfo {
> string noi_curpath; /* current file handle path (if any) */
> cred_t *noi_cred; /* credentials */
> uint64_t noi_xid; /* transaction ID */
> } nfsv4opinfo_t;
>
> Below is a list of the probes along with the specific argument for
> each
> whose type is defined by the NFS v3 specification:
>
> probe name args[2]
> -- ---
> nfsv3:::op-access-start ACCESS3args *
> nfsv3:::op-access-done ACCESS3res *
> nfsv3:::op-commit-start COMMIT3args *
> nfsv3:::op-commit-done COMMIT3res *
> nfsv3:::op-create-start CREATE3args *
> nfsv3:::op-create-done CREATE3res *
> nfsv3:::op-fsinfo-start FSINFO3args *
> nfsv3:::op-fsinfo-done FSINFO3res *
> nfsv3:::op-fsstat-start FSSTAT3args *
> nfsv3:::op-fsstat-done FSSTAT3res *
> nfsv3:::op-getattr-startGETATTR3args *
> nfsv3:::op-getattr-done GETATTR3res *
> nfsv3:::op-lookup-start LOOKUP3args *
> nfsv3:::op-lookup-done LOOKUP3res *
> nfsv3:::op-link-start LINK3args *
> nfsv3:::op-link-doneLINK3res *
> nfsv3:::op-mkdir-start MKDIR3args *
> nfsv3:::op-mkdir-done MKDIR3res *
> nfsv3:::op-mknod-start MKNOD3args *
> nfsv3:::op-mknod-done MKNOD3res *
> nfsv3:::op-null-start -
> nfsv3:::op-null-done-
> nfsv3:::op-pathconf-start PATHCONF3args *
> nfsv3:::op-pathconf-donePATHCONF3res *
> nfsv3:::op-read-start READ3args *
> nfsv3:::op-read-doneREAD3res *
> nfsv3:::op-readdir-startREADDIR3args *
> nfsv3:::op-readdir-done READDIR3res *
> nfsv3:::op-readdirplus-startREADDIRPLUS3args *
> nfsv3:::op-readdirplus-done READDIRPLUS3res *
> nfsv3:::op-readlink-start READLINK3args *
> nfsv3:::op-readlink-doneREADLINK3res *
> nfsv3:::op-remove-start REMOVE3args *
> nfsv3:::op-remove-done REMOVE3res *
> nfsv3:::op-renamestart RENAME3args *
Seems to be a typo in the above.
Spencer
> nfsv3:::op-rename-done RENAME3res *
> nfsv3:::op-rmdir-start RMDIR3args *
> nfsv3:::op-rmdir-done RMDIR3res *
> nfsv3:::op-setattr-startSETATTR3args *
> nfsv3:::op-setattr-done SETATTR3res *
> nfsv3:::op-symlink-startSYMLINK3args *
> nfsv3:::op-symlink-done SYMLINK3res *
> nfsv3:::op-write-start WRITE3args *
> nfsv3:::op-write-done WRITE3res *
>
> Note that op-null-* probes have an undefined args[2].
>
> Documentation and examples can be found here:
>
> http://wikis.sun.com/display/DTrace/nfsv3+Provider
>
> The table below describes the DTrace stability levels
>
> | Name
DTrace NFS v3 Provider [PSARC/2008/050 FastTrack timeout 01/24/2008]
On Thu, Jan 24, 2008 at 07:55:05PM -0800, John Plocher wrote:
> > typedef struct nfsv3opinfo {
> >...
> > } nfsv4opinfo_t;
>
> Is this a typo? i.e., the _t is a nfsv*4*, but the struct is a v*3*:
Yes; of course that should be nfsv3opinfo_t (there was obviosly a bit of
copying and pasting between the v4 and v3 providers).
> > nfsv3:::op-renamestart RENAME3args *
>
> Seems to be a typo in the above.
Yes, this should be op-rename-start.
Thanks.
Adam
--
Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl
2008/046 Process Contract Decorations
Gary Winiger wrote: >> There is no security vulnerability in not requiring privilege to set the >> "Service FMRI". Requiring privilege has the goal of making the term >> "Service FMRI" a trusted, system-wide name for observability purposes. >> Just as the SMF service FMRI is today. > > Hummm, is that really worth adding a privilege and requiring > ctrun to be called with that privilege? What's the risk of > the FMRI being spoofed on a contract? The FMRI term as proposed is intended to allow an administrator to reliably identify where each contract on the system originates from. Since creating a new contract doesn't require privilege, permitting any contract creator to set the FMRI term limits observability and impedes forensic analysis. > > What Rights Profile is being proposed to grant ctrun privilege? A new Rights Profile named "Process Contract Identifier" should be amended to this case. > And who should be granted this profile? Users who are responsible for creating service-like collections of processes that the administrator has decided should be identified separately from services started by SMF Antonello
2008/046 Process Contract Decorations
Nicolas Williams wrote: > Is there a stable DTrace interface to get at a contract's decorations? There are many possible consumers of these new terms. DTrace is only one such consumer, and can be designed separately from this case and in parallel with other consumers. > > The problem with inheritting the FMRI from the contract's parent > contract is that login sessions' contracts (which are created primarily > to be distinct from that of the service that performed the login) and > sub-contracts will have an FMRI that is not necessarily useful -- the > FMRI decoration will only be useful in conjunction with a bit indicating > whether the FMRI was inheritted. process(4) man page diff has code example to check if the "Service FMRI" was inherited or not. > > And if you wanted to you could make the privilege work sligthly > differently: rather than use the privilege to authorize the contract > identity set operation the kernel could simply set a one-bit decoration > value indicating whether the contract creator had that privilege. The "Creator Auxiliary" field was designed to permit an unprivileged contract creator to tag the contract. Antonello
2008/046 Process Contract Decorations
On Fri, Jan 25, 2008 at 07:40:55AM -0800, Antonello Cruz wrote: > Gary Winiger wrote: > > What Rights Profile is being proposed to grant ctrun privilege? > A new Rights Profile named "Process Contract Identifier" should be > amended to this case. > > > And who should be granted this profile? > Users who are responsible for creating service-like collections of > processes that the administrator has decided should be identified > separately from services started by SMF But will there be such users? It strikes me that this is a privilege that only restarters will need, and those should be services themselves, able to obtain this privilege straight from svc.startd. I.e., services that use ctrun to implement a restarter, or which use librestart may need this privilege, and they should have that privilege as part of the start method context. I can't imagine applications that are not SMF services requiring this privilege (except, perhaps, for debugging). So a rights profile to go with this privilege seems unnecessary. IMO, Nico --
Integrate LSI MegaRAID SAS controllers (eg. 1078) driver (mega_sas) into Solaris [PSARC/2008/051 FastTrack timeout 02/01/2008]
Alan Hargreaves wrote: > I'm not sure what happened to the email on this from sac_nextcase, so > I am resending it (also to the Bcc's it should have gone to). > > I am sponsoring this case for Susan Schuefele and Meera Mankali. The > timer is set for February 1. > > As a Solaris 10 version is planned, this project requests a patch > binding. > > It should be noted that I also sponsored 2008/011 which on first glance > would appear to conflict with this case. > > The parties involved from both groups have been in discussion. It has > been agreed that both drivers can co-exist and that the mega_sas driver > will integrate first. Expect more information in 2008/011 about how the > co-existence will happen. 2008/011 will remain in waiting spec update > until the details have been worked out and any new dependencies added. I am greatly interested (and concerned) with this idea of coexistence. I'm a little worried that this direction lies madness. The other FOSS systems that allow different drivers for the same hardware can probably cite it as one of the greatest causes for confusion and support headaches. The PRISM drivers (there are last I checked at least 3 of them) for Linux are a classic example of this. The other thing I am concerned with is that the LSI product is going to be (IIUC) fully open. (At least the kernel driver. I guess the userland administration tools are not. But this is LSI value-add compared to mfi.) If there is no licensing benefit gained by mfi, and no support benefit gained (indeed, I think its probably less support, since I think LSI will support their version of the driver), then I see little point in pressing forward with mfi. I'd really like to see the problem of driver coexistence treated separately, if that is the goal, rather than attempting to shim it into this case. Its a big enough problem that I don't think it is something that can or should be fast-tracked, but probably deserves a full case of its own. (There are so many questions I can ask here, that it boggles the mind.) -- Garrett
64 bit offsets for VOP_DUMP [PSARC/2008/053 FastTrack timeout 02/01/2008]
I'm submitting this fast-track for Bob Mastors. Requested binding is MINOR. Time-out is 1 Feb, 2008. Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: 64 bit offsets for VOP_DUMP 1.2. Name of Document Author/Supplier: Author: Bob Mastors 1.3 Date of This Document: 25 January, 2008 4. Technical Description INTRODUCTION The vnode operation VOP_DUMP uses 32-bit values for block addressing. This prevents system crash dumps and cpr statefiles from being saved on very large devices via VOP_DUMP. PROPOSED CHANGES Change block offset and lengths to type offset_t for VOP_DUMP and VOP_DUMPCTL. Change corresponding functions in FEM, file event monitoring. Change file system implementations of VOP_DUMP and VOP_DUMPCTL to work with the new types. Change callers of the above VOP/FEM functions as needed. The VFSDEF_VERSION number in sys/vfs.h will be bumped from 4 to 5 in order to prevent unbundled file system kernel modules with the old signatures from loading. Once the unbundled file system modules are updated with the new signatures and recompiled, they will also pick up the new VFSDEF_VERSION number and be allowed to load. All of the ON file systems will be updated with these changes. Unbundled file system developers (internal and external) will be given a heads up about these changes. Rich Brown is coordinating a TOI on all file system changes made in Solaris Nevada. Note that Solaris Nevada now performs strong type-checking on vnode/FEM operations. This means that the compilers will inform unbundled file system developers of the signature discrepancy in their code. DEVICE DRIVER INTERFACE No changes are proposed to the device driver interface. File system specific dump functions typically call the DDI routine bdev_dump which has the following signature: int bdev_dump(dev_t dev, caddr_t addr, daddr_t blkno, int blkcnt) bdev_dump calls the underlying device dump(9e) function which has the same signature. On the 64-bit solaris kernel, daddr_t is 64-bits. However on the 32-bit solaris kernel, daddr_t is a 32-bit value. bdev_dump and device driver dump(9e) functions have the following characteristics: 64-bit device drivers have 64-bit block addressing and 32-bit block counts. 32-bit device drivers have 32-bit block addressing and 32-bit block counts. Current consumers of VOP_DUMP limit the transfer size to a few megabytes at a time. They do not overflow the 32-bit block count. 32-bit block addressing results in the following limitation. A file should not be used as the dump device or cpr statefile when all of the following conditions occur: a) the solaris kernel is compiled 32-bit b) the file system is UFS c) the file system is larger then 1 TB This limitation may also apply to unbundled file systems. ZFS does not have this limitation because it does not support files as dump devices or cpr statefiles. The fop_dump() function will be changed to perform safety checks to ensure the offset and length passed to VOP_DUMP can be passed onto bdev_dump safely. fop_dump will return EIO if the values cannot be passed safely. These safety checks may be removed in the future if the DDI dump(9e) signature is modified to support 64-bit addressing and 64-bit block counts on all architectures. ALTERNATIVES TO OFFSET_T The selection of "offset_t" for the type of the block address and block count seemed consistent with usage in other VOP functions and "struct uio". Also offset_t is a signed value, as are the types it is replacing. Alternatives considered include the following: typedef u_longlong_tdiskaddr_t; typedef u_longlong_tlen_t; typedef u_longlong_tu_offset_t; typedef uint64_tpaddr_t; RELATED CASES PSARC/2001/679 Vnode Interfaces 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) RELATED CR 6214480 System crash dump fails when dump device is > 1 TB DELIVERY These modifications are intended to be part of Solaris Nevada. MODIFIED INTERFACES +---+--++ | Interface| Classification | Comments | +---+--++ | | Contracted || | VOP_DUMP, | Consolidation| changed block addr and len | | fop_dump | Private | to offset_t| | |
2008/046 Process Contract Decorations
Nicolas Williams wrote: > On Fri, Jan 25, 2008 at 07:40:55AM -0800, Antonello Cruz wrote: >> Gary Winiger wrote: >>> What Rights Profile is being proposed to grant ctrun privilege? >> A new Rights Profile named "Process Contract Identifier" should be >> amended to this case. >> >>> And who should be granted this profile? >> Users who are responsible for creating service-like collections of >> processes that the administrator has decided should be identified >> separately from services started by SMF > > But will there be such users? It strikes me that this is a privilege > that only restarters will need, and those should be services themselves, > able to obtain this privilege straight from svc.startd. > > I.e., services that use ctrun to implement a restarter, or which use > librestart may need this privilege, and they should have that privilege > as part of the start method context. > > I can't imagine applications that are not SMF services requiring this > privilege (except, perhaps, for debugging). I can think of development of new restartes or services that create contracts, which probably falls in your debugging set. > > So a rights profile to go with this privilege seems unnecessary. I agree it seems overkill to create a new Rights Profile. I don't feel strongly either way. What do others think? Antonello
