Patch Name: PHKL_21660 Patch Description: s700 10.20 lo_realvfs panic fix, Cumulative LOFS patch Creation Date: 00/05/09 Post Date: 00/05/12 Repost: 00/05/16 The Symptoms information in the patch documentation was modified to add stack trace information for the problem addressed by PHKL_21660. Only the patch documentation was modified, the files installed by the patch were not changed. Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_21660: PANIC PHKL_20482: PANIC PHKL_18521: HANG PHKL_17012: OTHER The behavior using lofs file systems is unpredictable if PHKL_16750 is installed because a partial lofs fix was delivered in this patch. Path Name: /hp-ux_patches/s700/10.X/PHKL_21660 Symptoms: PHKL_21660: (SR: 8606132691 CR: JAGad01839) Users see a PANIC with 'lo_realvfs' message. The following stack trace is seen: panic+0x14 lo_realvfs+0x9c freelonode+0xdc lo_inactive+0x124 locallookuppn+0x4fc lookuppn+0xf8 lookupname+0x40 vn_open+0x68 copen+0xd0 open+0x3c syscall+0x480 $syscallrtn+0x0 PHKL_20482: ( SR: 8606109444 CR: JAGab82146 ) A system may panic in lo_realvfs() when using LOFS file systems. PHKL_18521: ( SR: 4701423798 CR: JAGab13874 ) The system may hang using LOFS if the directory being mounted and the mount point to are the same. To reproduce the problem: # mount -F lofs /mnt /mnt # ls /mnt This process will loop in the kernel indefinitely. PHKL_18439: ( SR: 4701422105 CR: JAGab03795 ) /usr/bin/pwd incorrectly fails. To reproduce the problem: # mkdir -p /tmp/lofs1 /tmp/lofs2 # mount -F lofs /var/adm /tmp/lofs1 # mount -F lofs /var/adm /tmp/lofs2 # cd /tmp/lofs1/sw/products # /usr/bin/pwd This will fail with "No such file or directory" instead of returning /tmp/lofs1/sw/products. PHKL_17012: ( SR: 5003442988 DTS: JAGaa43747 ) Various symptoms may be exhibited due to a partial fix being delivered to a previous patch. One reported symptom includes getting a "Device Busy" error when trying to mount a file system a second time using lofs. The failure that caught this issue can be reproduced by doing mkfs /dir1 /dir2 mount -F lofs /usr /dir1 mount -F lofs /usr /dir2 The result of the second mount will be "Device Busy". Defect Description: PHKL_21660: (SR: 8606132691 CR: JAGad01839) This PANIC with 'lo_realvfs' message is because of a race condition. A race condition is created when one thread tries to create an lfs node and another thread tries to release the same 'lfs' node. Thread 1 tries to free an 'lfs' node while holding a lock. Thread 2 tries to make an 'lfs' node. But, due to the time gap in holding and releasing the lock, a race condition is created between Thread 1 and Thread 2. This can lead to the PANIC with 'lo_realvfs' PANIC. Resolution: The fix is to increase and decrease the lfs_refct without giving up the lock. Also the lfs_refct value checking has been changed to reflect the new change. PHKL_20482: ( SR: 8606109444 CR: JAGab82146 ) The problem is a race condition caused by not properly protecting an entry in a lofs data structure. The lock that is supposed to protect this structure was not held when an update was made, and thus simultaneous changes resulted in an inconsistency in the data structure, causing the panic. Resolution: The lock is now held when this entry is updated; this is actually just obtaining the lock one line earlier in the code. PHKL_18521: ( SR: 4701423798 CR: JAGab13874 ) The problem is that the system will loop in the routine trying to find the root of the file system. Resolution: The mount of a directory to itself is really an error. The resolution is to change the code so the mount will fail with EINVAL, thus avoiding the case where the hang will occur. PHKL_18439: ( SR: 4701422105 CR: JAGab03795 ) The command /usr/bin/pwd, which calls getcwd(), incorrectly fails with certain lofs file systems. The problem is caused by the lofs routine lfind() returning the incorrect vnode when searching for the lofs directory. Resolution: A change had been added in patch PHKL_15619 that allowed an incorrect vnode to match the one we were searching for in lfind(). This check is not necessary to fix the original problem, and has been removed. PHKL_17012: ( SR: 5003442988 DTS: JAGaa43747 ) The defect was caused by having only 2 of the 6 files delivered into patches PHKL_1659[2,3] for various lofs problems. The problem is corrected by delivering all 6 of the files needed to correct lofs defects. SR: 4701422105 4701423798 5003442988 8606109444 8606132691 Patch Files: /usr/conf/lib/libhp-ux.a(lo_subr.o) /usr/conf/lib/libhp-ux.a(lo_vfsops.o) /usr/conf/lib/libhp-ux.a(lo_vnops.o) /usr/conf/lib/libhp-ux.a(vfs.o) /usr/conf/lib/libhp-ux.a(vfs_vnode.o) what(1) Output: /usr/conf/lib/libhp-ux.a(lo_subr.o): lo_subr.c $Date: 2000/05/08 11:59:47 $ $Revision: 1. 4.98.10 $ PATCH_10.20 (PHKL_21660) /usr/conf/lib/libhp-ux.a(lo_vfsops.o): lo_vfsops.c $Date: 99/05/03 13:26:19 $ $Revision: 1. 4.98.9 $ PATCH_10.20 (PHKL_18521) /usr/conf/lib/libhp-ux.a(lo_vnops.o): lo_vnops.c $Date: 98/11/25 06:46:32 $ $Revision: 1.5 .98.8 $ PATCH_10.20 (PHKL_17012) /usr/conf/lib/libhp-ux.a(vfs.o): vfs.c $Date: 98/11/25 06:47:02 $ $Revision: 1.25.98. 17 $ PATCH_10.20 (PHKL_17012) /usr/conf/lib/libhp-ux.a(vfs_vnode.o): vfs_vnode.c $Date: 98/11/25 06:47:17 $ $Revision: 1. 14.98.10 $ PATCH_10.20 (PHKL_17012) cksum(1) Output: 2355190603 5340 /usr/conf/lib/libhp-ux.a(lo_subr.o) 3247518269 3680 /usr/conf/lib/libhp-ux.a(lo_vfsops.o) 3226911052 6328 /usr/conf/lib/libhp-ux.a(lo_vnops.o) 2007819174 20440 /usr/conf/lib/libhp-ux.a(vfs.o) 4247523880 8988 /usr/conf/lib/libhp-ux.a(vfs_vnode.o) Patch Conflicts: None Patch Dependencies: s700: 10.20: PHKL_16750 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_17012 PHKL_18439 PHKL_18521 PHKL_20482 Equivalent Patches: PHKL_21661: s800: 10.20 PHKL_21608: s700: 11.00 Patch Package Size: 110 KBytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHKL_21660 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_21660.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_21660. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. WARNING: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHKL_21660.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_21660.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: This patch depends on base patch PHKL_16750. For successful installation, please ensure that PHKL_16750 is in the same depot with this patch, or PHKL_16750 is already installed.