Calling parameters

What should have been forwarded to fifo_rdwr() ? Referring to the source code, we see that the calling parameters are: vp , uiop , rw , ioflag , and cred . A vp refers to a vnode pointer, or a pointer to a vnode structure. Unfortunately, register %i0 conditionally gets modified early on at either fifo_rdwr+0x18 or fifo_rdwr+0x2c , so we don't have the original vnode pointer with which to work.

Note

If you don't have access to source, refer to the 4.1.3 function list which you'll find on the Panic! CD-ROM.

Let's back up a bit instead.

The routine that called fifo_rdwr() was vno_rw() . Its calling parameters are fp , rw , and uiop. Fp refers to a file pointer, or in other words, a pointer to a file structure. To find out what a file structure looks like, we refer to the SunOS 4.1.3 /usr/include/sys/file.h header file, a portion of which is shown below.

 /*   * Descriptor table entry.   * One for each kernel object.   */  struct  file {         int     f_flag;         /* see below */          short   f_type;         /* descriptor type */          short   f_count;        /* reference count */          short   f_msgcount;     /* references from message queue */          struct  fileops {                 int     (*fo_rw)();                  int     (*fo_ioctl)();                  int     (*fo_select)();                  int     (*fo_close)();          } *f_ops;        caddr_t f_data;      /* ptr to file specific struct (vnode/socket) */  off_t   f_offset;          struct  ucred *f_cred;  /* credentials of user who opened file */  };  struct  file *file, *fileNFILE; 

Now, back in adb , we will use the file macro to see if the first calling parameter to vno_rw() appears to be valid.

  $c  _panic(0xf8120eb1,0xf86e8cbc,0xffffffff,0x30,0x7c375,0xf7fffdf0) + 6c  _trap(0x7,0xf86e8cbc,0xffffffff,0x30,0x0,0x0) + 2a0  st_have_window(?)  _uiomove(0x0,0x0,0x1000,0x2,0x1002,0x2) + 98  _fifo_rdwr(0xfceaccb0,0xf86e8eac,0x0,0xfceb2525,0x2,0x0) + 5ac  _vno_rw(  0xf835bac8  ,0x1,0xf86e8eac,0x1000,0xfceaccb4,0x0) + a4  _rwuio(0xf835bac8,0xf86e8eac,0xf86e8ea4,0x1000,0x1000,0xf86e8eac) + 2b0  _write(0xf86e8fe0,0x20,0xf8114ad0,0xf8114af0,0xf86e9000,0xf8114af0) + 34  _syscall(0xf86e9000) + 3b4  0xf835bac8$<file  0xf835bac8:     flag            type    count   msgcount                  102             1       3       0                  vnode           offset          cred                  fceaccb4        0               ff1c1514 

Well, that's encouraging. When compared with the definition of the file structure as described in file.h , the %i0 value appears to be a valid pointer to a file structure.

Next question: Does the file structure appear to point to a valid vnode structure? Let's see. First, let's look at the vnode structure, as described in /usr/include/sys/vnode.h.

 /*     * vnode types. VNON means no type.     */    enum vtype      { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VBAD, VFIFO };  struct vnode {         u_short         v_flag;                 /* vnode flags (see below) */          u_short         v_count;                /* reference count */          u_short         v_shlockc;              /* count of shared locks */          u_short         v_exlockc;              /* count of exclusive locks */          struct vfs      *v_vfsmountedhere;      /* ptr to vfs mounted here */          struct vnodeops *v_op;                  /* vnode operations */          union {                 struct socket   *v_Socket;      /* unix ipc */                  struct stdata   *v_Stream;      /* stream */                  struct page     *v_Pages;       /* vnode pages list */          } v_s;          struct vfs      *v_vfsp;                /* ptr to vfs we are in */          enum vtype      v_type;                 /* vnode type */          dev_t           v_rdev;                 /* device (VCHR, VBLK) */          long            *v_filocks;             /* File/Record locks ... */          caddr_t         v_data;                 /* private data for fs */  }; 

And now, let's return to our adb session and see if we can have a valid vnode pointer.

  fceaccb4$<vnode  0xfceaccb4:     flag    refct   shlockc exlockc                  2       2       0       1  0xfceaccbc:     vfsmnt          vop             pages           vfsp                  0  f8117b00  0               fce05fc8  0xfceacccc:     type            rdev            data  8  0       0       fceaccb0  f8117b00/P  _fifo_vnodeops:  _fifo_vnodeops: _fifo_open 

Yes, it looks like a good vnode structure, and it references the fifo file system operation routine fifo_open , which tells us we are dealing with a fifo. The vnode type of 8 confirms this observation.