Patch Name: PHKL_23961 Patch Description: s700 10.20 HFS Panic moving directories & Hang in lockorder Creation Date: 01/04/19 Post Date: 01/04/23 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_23961: HANG PHKL_16869: PANIC PHKL_12059: HANG Path Name: /hp-ux_patches/s700/10.X/PHKL_23961 Symptoms: PHKL_23961: (SR: 8606183441 CR: JAGad52654) Hang in HFS due to a deadlock between two threads operating in the same directory. One thread is doing an open() on a file and the other thread is doing a rename (mv) of a file in the same directory. Following is a stack trace of the threads in deadlock: Trace of thread 1 ----------------- real_sleep+0x234 _sleep+0x14 dvp_sleep+0x58 use_dev_dvp+0x90 ufs_inactive+0 vn_rele+0x1e8 dnlc_rm+0x90 dnlc_purge1+0xec ieget+0x30c in_get+0x34 iget+0x14 dirlook_loop+0x3ac dirlook+0xc4 sdo_lookup+0x64 ufs_lookup+0x24 locallookuppn+0x864 ufs_lookup+0x24 locallookuppn+0x864 lookuppn+0xdc lookupname+0x30 vn_open+0x5c copen+0xc8 open+0x20 syscall+0x75c $syscallrtn+0x0 Trace of thread 2 ---------------- _swtch+0x138 real_sleep+0x234 _sleep_one+0x14 ilock+0x80 direnter+0xa8 ufs_rename+0xec vn_rename+0x234 rename+0x28 syscall+0x75c $syscallrtn+0x0 PHKL_16869: Getting Data Page Fault when moving a subdirectory to another sub-directory. PHKL_12059: UFS hangs with heavy use of a filesystem branch by multiple processes. The hang is due to a three way deadlock with inodes and bufs being held but not released. This shows up with the buf being both B_BUSY and B_DONE but not being released. PHKL_8463: The directory entry for an HFS file system object (FSO) is still readable even after the contents of that object have been deleted. This is a roadblock to C2 Security certification. Defect Description: PHKL_23961: (SR: 8606183441 CR: JAGad52654) The first thread is in open() and has locked the directory inode in dirlook_loop(). Then it calls dnlc_purge1() because there are no inodes on the inode free list, which subsequently sleeps waiting to lock the device vnode. The second thread is doing a mv of a file in the same directory as the first thread and is in a rename() system call. It locks the device vnode in ufs_rename() and proceeds to sleep waiting for the directory inode held by the first thread. Resolution: Avoid calling dnlc_purge1() in the open path by verifying the status of inode freelist as soon as we lock the directory inode. If the free list is empty purge and recover inodes at this point. This will avoid calling dnlc_purge1() further down the open() path. PHKL_16869: The problem will only occur on HFS filesystems using short filenames. Instead of using the short filename pointer, the code was incorrectly using the long file name pointer which at this point had not yet been properly initialized. Dereferencing this uninitialized pointer caused a data page fault. PHKL_12059: Problem was due to incorrectly releasing an inode while still holding a buf. This violates the rule which would prevent a deadlock from happening. The problem shows up as a three way deadlock with two processes marching back to the root from the leaves via ".." and another process marching from the root to the leaves. This creates a a deadlock of processes waiting for the same inode and holding the wanted buf at the same time. PHKL_8463: The name of a file in an HFS directory entry is not cleared when the file object itself is deleted (say, with rm(1)). To demonstrate this: $ mkdir test $ cd test $ touch delete_me $ ls delete_me $ rm delete_me $ ll total 0 $ strings . # Examine strings in cwd. delete_me # Filename is still in cwd entry. The same defect exists in the journaled file system (VxFS); this fix does not address that defect. SR: 1653182501 4701334839 4701403725 8606183441 Patch Files: /usr/conf/lib/libufs.a(ufs_dir.o) what(1) Output: /usr/conf/lib/libufs.a(ufs_dir.o): ufs_dir.c $Date: 2001/04/19 10:31:41 $ $Revisio n: 1.22.98.11 $ PATCH_10.20 (PHKL_23961) cksum(1) Output: 2460403393 20000 /usr/conf/lib/libufs.a(ufs_dir.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_8463 PHKL_12059 PHKL_16869 Equivalent Patches: PHKL_23962: s800: 10.20 Patch Package Size: 80 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_23961 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_23961.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_23961. 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_23961.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_23961.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None