Patch Name: PHKL_20610 Patch Description: s700 10.20 Correct process hangs on ufs inodes Creation Date: 99/12/20 Post Date: 00/01/10 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_20610: HANG PHKL_19158: HANG PHKL_17253: HANG Path Name: /hp-ux_patches/s700/10.X/PHKL_20610 Symptoms: PHKL_20610: ( SR: 8606108620 CR: JAGab79067 ) Note that for this patch the symptoms are the same as the patch it supersedes. This patch addresses a second, and similar, race condition. Processes reading/writing inodes on a ufs file system may sleep (and hang) indefinitely waiting for the inode lock to become available. PHKL_19158: ( SR: 8606100744 CR: JAGab31988 ) Processes reading/writing inodes on a ufs file system may sleep (and hang) indefinitely waiting for the inode lock to become available. PHKL_17253: ( SR: 5003446260 DTS: JAGaa45712 ) Processes reading/writing inodes on a ufs file system may sleep (and hang) indefinitely waiting for the inode lock to become available. This problem was introduced in patch PHKL_16592. Defect Description: PHKL_20610: The problem is race condition where an inode is being purged. There are two possibilities during this process (In PHKL_19158 we only addressed the first possible race condition): 1. Before the inode been moved to freelist, several threads find this inode on the head of the incore inode list, and sleep on it waiting to do their read/write; 2. After the inode been moved to freelist, the first thread which was waiting for it was wakened up and locked the inode, but at same time other threads trying to get a free inode will get the same inode from freelist, and they will all sleep on that inode since it has been locked by the first thread. Both conditions cause multiple threads sleeping on one inode of which the identity or status is about to be changed (to be moved from inode list to freelist, and/or from freelist to inode list). If the inode identity or status has been changed during the sleep time, after waking up and retrying, a thread will get a new inode which is different from the old one it was sleeping on last time, and continue processing with the new inode without waking up the rest of threads that are still sleeping on the old inode. Those threads will hang forever. Resolution: The solution is waking up the next sleeper which is still sleeping on the old inode if the new inode is different from the old one. PHKL_19158: ( SR: 8606100744 CR: JAGab31988 ) The problem is race condition where an inode is being purged. During this process, several threads find this inode on the head of the incore inode list, and sleep on it waiting to do their read/write. When the inode is being purged, it is placed on the freelist, and yet another thread finds it there and changes the inode's identity. While the threads sleeping on the original identity will properly check for this condition, and find a different inode once awakened, the problem is that if a number of threads are sleeping on the original identity, they may not all be awakened. So, some threads may hang forever. Resolution: The solution is to wake up all readers and writers sleeping on an incore inode when a purge of that inode is done. When this happens, the processes will realize the identity of the inode has changed, and will properly look for a different inode. PHKL_17253: ( SR: 5003446260 DTS: JAGaa45712 ) The problem is in ip_sharable(), a check to determine whether additional read locks can be done. The check incorrectly passes when an inode is ILOCKED and IPAUSED, causing these additional read requests to be added. These read requests will never be serviced because the counts on the inode will be incorrect. Resolution: The resolution is to correct the ip_sharable() check so that read requests are delayed properly in order to keep the inode request counts accurate. This will prevent a hang from occurring on these processes. This change is minimal and provides the behavior intended in PHKL_16592. SR: 5003446260 8606100744 8606108620 Patch Files: /usr/conf/lib/libufs.a(ufs_inode.o) what(1) Output: /usr/conf/lib/libufs.a(ufs_inode.o): ufs_inode.c $Date: 99/12/20 09:33:00 $ $Revision: 1. 48.98.23 $ PATCH_10.20 (PHKL_20610) cksum(1) Output: 1963202925 26436 /usr/conf/lib/libufs.a(ufs_inode.o) Patch Conflicts: None Patch Dependencies: s700: 10.20: PHKL_16750 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_17253 PHKL_19158 Equivalent Patches: PHKL_20611: s800: 10.20 Patch Package Size: 90 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_20610 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_20610.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_20610. 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_20610.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_20610.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.