OpenSolaris

Printable Version Enter a New Search
Bug ID 6587501
Synopsis NFS client failed on TX down-label access to unlabeled node
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:other
Keywords onpit-tx
Responsible Engineer Casper Dik
Reported Against snv_68
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_73
Fixed In snv_73
Release Fixed solaris_nevada(snv_73)
Related Bugs 6549515
Submit Date 31-July-2007
Last Update Date 15-September-2007
Description
I have been trying to do a live-upgrade of my office workstation (an
ultra-45 sparc system running snv_68 with TX configured). My system
is running with our group's typical test zones configured:

sh-3.00# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   1 public           running    /txzone/public                 native   shared
   2 internal         running    /txzone/internal               native   shared
   3 sandbox          running    /txzone/sandbox                native   shared
   4 restricted       running    /txzone/restricted             native   shared
   5 needtoknow       running    /txzone/needtoknow             native   shared

The Solaris install image is at /net/zhadum.east/export/install/nv/s/latest/.

I have no problem accessing the image directory from the internal zone:

wawbeek$ ls /net/zhadum.east/export/install/nv/s/latest/
Copyright                     Solaris_11/
JDS-THIRDPARTYLICE

But cannot access it from the global zone.

sh-3.00# ls /net/zhadum.east/export/install/nv/s/latest/
/net/zhadum.east/export/install/nv/s/latest/: Permission denied


zhadum is defined as an unlabeled node with a default label of internal.

wawbeek$ getent ipnodes zhadum.east
10.8.57.30      zhadum.east.sun.com
10.8.57.1       zhadum.east.sun.com
10.8.57.2       zhadum.east.sun.com

wawbeek$ tninfo -h 10.8.57.30
IP address= 10.8.57.30
Template = internal
wawbeek$ tninfo -h 10.8.57.1
IP address= 10.8.57.1
Template = internal
wawbeek$ tninfo -h 10.8.57.2
IP address= 10.8.57.2
Template = internal

wawbeek$ tninfo -t internal
=====================================
Remote Host Template Table Entries:
__________________________
template: internal
host_type: UNLABELED
doi: 1
def_label: CNF : INTERNAL USE ONLY
hex: 0x0004-08-48
For routing only:
min_sl: ADMIN_LOW
hex: ADMIN_LOW
max_sl: ADMIN_HIGH
hex: ADMIN_HIGH


/export/install/nv and /export/install are separate zfs file systems on zhadum and
are listed in zhadum's /etc/dfs/sharetab as:

/export/install -       nfs     anon=0,sec=sys,ro
/export/install/nv      -       nfs     anon=0,sec=sys,ro


The following messages were recorded in /var/adm/messages when this
failure occurred.

Jul 26 14:19:35 wawbeek nfs: [ID 664466 kern.notice] NFS compound failed for server zhadum.east: error 26 (RPC: Couldn't make connection)
Jul 26 14:20:25 wawbeek last message repeated 5 times
Jul 26 14:20:25 wawbeek nfs: [ID 434519 kern.warning] WARNING: NFS server initial call to zhadum.east failed: I/O error
Jul 26 14:20:25 wawbeek automountd[4634]: [ID 834250 daemon.error] Mount of zhadum.east:/export/install on /net/zhadum.east/export/install: I/O error
Jul 26 14:20:25 wawbeek automountd[4634]: [ID 478478 daemon.error] mount of /net/zhadum.east/export/install failed


My ferrari notebook running snv_64 with TX configured does not encounter
this same failure.
I ran "dtrace -i tx-\*" while entering the following command in the global zone.

  ls /net/zhadum.east/export/install/nv/s/latest/

The following dtrace trigger fired.

  tsol_compute_label:tx-tnopt-log-info-labeling-mac-v4

One possible cause for this to fire is an unset mac-exempt flag on the connection.

I then ran identical commands in the internal zone and the global zone with
snoop enabled. I looked at the captured files with wireshark.

Both logs progressed about the same up till message 86 with

NFS V4 NULL Call
NFS V4 NULL Reply

and the following repeated 4 times.

Portmap V2 GETPORT Call MOUNT
Portmap V2 GETPORT Reply
MOUNT V1 EXPORT Call
MOUNT V1 EXPORT Reply

The TCP connection terminated and the global zone message exchange ended at
this poiint. The internal zone proceeded with a new TCP connection for:

NFS V4 COMPOUND CALL with Network File System operations
    PUTROOTFH
    LOOKUP with Filename: export
    SECINFO with Filename: install
Will reproduced this problem on both his office systems (sparc and x86).
His systems are running a nightly snv_69+ image.

He used dtrace to capture the stack down to tsol_compute_label at the time of
the failure. His dtrace output clearly showed the connection's mac-exempt flag
was indeed clear.

  1  32513         tsol_compute_label:entry
              ip`tcp_update_label+0xe6
              ip`tcp_rput_other+0x292
              ip`tcp_connect_ipv4+0x2fc
              ip`tcp_connect+0x463
              ip`tcp_wput_proto+0x202
              ip`squeue_enter+0x41a
              ip`tcp_wput+0x370
              unix`putnext+0x2f1
              rpcmod`mir_wput_other+0x3ff
              rpcmod`mir_wput+0x1d0
              rpcmod`rmm_wput+0x1e
              unix`put+0x270
              rpcmod`clnt_dispatch_send+0x11a
              rpcmod`connmgr_connect+0xee
              rpcmod`connmgr_wrapconnect+0x155
              rpcmod`connmgr_get+0x37f
              rpcmod`connmgr_wrapget+0x5f
              rpcmod`clnt_cots_kcallit+0x2e8
              nfs`nfs4_rfscall+0x4e2
              nfs`rfs4call+0xdd

              libc.so.1`mount+0x7
              automountd`mount_nfs+0xe6
              automountd`do_mount1+0x2ee
              automountd`autofs_mntinfo_1_r+0x8c
              automountd`autofs_doorfunc+0x2dd
              libc.so.1`__door_return+0x52
result: cred -5276570256 is_exempt? 0
Work Around
N/A
Comments
N/A